交通数据库系统（精选十篇）
交通数据库系统 篇1
1 空中交通监测系统的高速数据传送结构分析
数据通信与传送是空中交通监测系统中重要的功能与结构部分, 高速的数据通信与传送软件, 对于保证整个空中交通监测系统的快速、实时与准确数据通信传输具有积极作用和意义。
本文所要论述的空中交通监测系统的高速数据传送结构, 也被称为是空中交通监测系统中的数据采集与存储系统结构, 它主要是由空中数据采集与存储系统和地面数据采集与存储结构系统两个结构部分组成。空中交通监测系统数据采集与存储结构情况, 在数据采集与存储系统中, 空中系统结构部分主要是由图像采集设备以及定位与惯性平台、无线通信、计算机等结构单元组成, 其中, 数据采集与存储空中, 系统中的图像采集设备主要有高分辨率的数码照相机, 以及彩色摄像机、红外摄像机等, 分别安装于空中交通监测系统的头尾两个结构部分;定位与惯性平台结构单元主要是用于进行准确定位和姿态校正;机载移动计算机设备则是一个小型的嵌入式计算机控制单元设备具有较好的稳定性与兼容性, 并且使用过程中能耗比较低。而空中交通监测系统中数据采集与存储的地面系统结构部分, 通常根据运行监测与管理的实际需求, 多设置在地面交通指挥中心, 主要是由服务器以及通信系统设备等组成。
2 系统中高速数据采集与传输方式
空中交通监测系统中实现数据的高速采集与传输、存储, 主要是通过上述数据存储与采集系统中的高速串口ESCC-104-ET和视频采集卡MPEG4000两个单元部分实现的。其中, 在空中交通监测系统的数据通讯与传输过程中, 串口通讯是一种计算机数据进行交换实现的常用方法, 一般情况下, 在进行计算机数据交换应用中, 普通的串口通讯中数据进行交换与传输的最大速率为每秒38.4kb, 为了实现空中交通监测系统中数据的高速通讯传输, 上述数据采集与存储系统中对于图像采集实现专门使用特定的数码相机, 图像数据信息采集中不仅具有较大的视场角度, 并且像素单元也比较大, 供系统选择应用范围广, 在进行图像数据的存储中, 以CR2格式为例, 平均一副图像文件的大小约为16Mb, 下穿图片以JPEG格式为主, 其压缩比为1:8, 对于浏览效果不存在较大影响。通常情况下, 普通串口进行一幅静态JPEG图片下载实现平均需要时间超过空中监测系统在空中循环运行中停留的时间, 因此, 为了满足对于图像信息的传输, 就需要此阿勇高速串口通讯方式进行图像传输实现。高速串口通讯卡主要采用PCI总线控制方式, 以Siemes 82532芯片进行设计实现, 具有一边进行数据接收和一边进行存储、下传的功能。
此外, 为了实现空中交通监测系统对于路面交通情况的实时监测与高速数据通信, 系统中还应用了MPEG4000采集卡, 以对于系统中摄像机采集的视频数据进行转换、压缩与通信传输实现, 同时该采集卡也是一个视频采集模数的转换以及压缩硬件接口卡, 以实现对于空中交通监测系统中数据信息的高速通信传输实现。目前, 该数据采集与存储方式在实际空中交通监测中已经有较多的设计实现和应用。
3 应用前景
国外俄、德、日、美等国, 已经相继实现了空中监视地面交通, 同时应用在了多届的奥运会中。当下, 我国的上海、广州等地交警, 都在配备空中的交通检测平台, 若可以运用该项数字技术, 一定会提升其自动化程度。
4 结束语
高速数据传送是一种能够满足空中交通监测系统快速、同步、实时并且准确的进行数据通讯传输的一种方式, 进行该方式的分析研究, 有利于在空中交通监测中的推广应用, 具有积极作用和意义。
参考文献
[1]汪磊, 孙瑞山.空中交通管制员疲劳状态实时监测方法的实现[J].安全与环境工程.2013 (4) .
[2]方薇, 钱玮, 张冬英, 罗军, 方廷健.空中交通监测系统高速数据传输方法[J].计算机与现代化, 2012 (03) .
交通数据库系统 篇2
摘要：交通规划数据库将各类规划的交通专项部分加以整合、处理、建库，可实现在GIS环境下集中展现交通专项规划的需求，对于交通规划编制、审批及研究提供大量的数据和技术支持。道路红线规划作为重庆重要的交通专项规划，在交通规划数据库中对其进行了单独建库。据此，主要研究在ArcSDE数据库中建立基于道路红线规划cad成果的专题数据库的建库规则，建库规则包括制图规则和专题数据属性规则。
关键词：道路红线规划；建库；规则
中图分类号：TB
文献标识码：A
doi：10.19311/j.cnki.16723198.2017.11.100
0引言
开展交通规划编制、规划审批的工作过程中，需要各类数据的支撑，包括法定规划（如总规、控规）、交通专业规划、交通专项规划及交通研究等。然而，总规的深度不足以指导具体交通规划的编制，而由于控规编制的特点，道路网很难从城市的整体角度考虑道路等级、道路标准等，为指导道路规划带来一定局限。为更好地指导道路规划的编制及审批，重庆市开展了道路红线规划专项工作，深度达到控制性详细规划的深度，为更系统地指导道路规划编制、审批提供更有力的支撑。
道路红线规划编制工作完成后，如何将规划成果建立数据库，按照交通专业的需求赋予相关属性，全面支撑后续的规划编制、管理工作，是一项极其重要且比较复杂的工作。
1规划成果数据库现状
规划管理部门已建立用于辅助规划管理的数据库应用系统，但目前数据的建库方式，主要针对地块进行，将单个地块对象进行建库，道路规划成果只是简单地将cad成果文件导入到空间数据库中，使用时类似于直接打开cad成果文件，并没有像地块建库一样，作为独立的对象进行入库，导致道路规划成果只能进行简单的浏览查看，不能根据需求进行相关的统计分析工作。这种状况导致在交通编制、审批时难以提供丰富的支持工作。
为更好地辅助交通规划的编制、审批及研究工作，能够开展相关的统计分析任务，需对道路红线规划cad成果建立专题数据库，并将道路作为单独对象进行建模、道路属性入库，实现按道路等级浏览、统计各道路专业指标（道路长度、道路面积、道路网密度、道路面积率）等。在将成果数据入库前，需根据应用需求，研究道路红线规划成果特点，制定专题数据库的入库规则，让数据库的数据满足相关应用需求。
2道路红线规划建库内容
根据建库目标，为各交通规划编制、审批及研究提供数据支撑，入库数据包括两方面：一是规划的原始成果，需根据审批通过的原始成果原样入库；二是加工成果，包括用于关联规划道路各属性的道路中心线，为统计分析工作道路红线面、公交站点、人行立体过街设施等。本次建库规则研究的对象，主要是加工的成果，包括：道路中心线、道路红线、公交站点、人行立体过街设施。
3道路?t线规划建库规则
本文的建库规则基于ArcSDE数据库。规则由两方面组成：一是空间制图入库规则，二是对象属性入库规则。
3.1道路中心线
3.1.1制图规则
根据道路红线规划成果，提取道路中心线，并在道路中心线的平面交叉口、立交匝道等交通分流、合流处打断，非交通分流、合流处合并为一个对象。
在处理道路中心线进行入库时，注意以下情况：
一是道路中心线不完整。规划人员在制图过程中，存在规划要素缺失的情况，在进行入库时，需根据已有的条件或规则，补充完善道路中心线，否则道路的属性无加载的对象，也会影响统计分析的正确性。缺失中心线时，可根据路缘石线、道路红线等，利用arcgis的“平行复制”或者“生成中心线”功能，补充完善道路中心线。
二是道路中心线分层错误。规划人员在图层分层过程中，并没有严格按照制图标准进行制图，导致通过提取cad成果的道路中心线图层的数据，存在路缘石线、道路红线或标注线等其他要素，同时存在真正的道路中心线放在了其他图层，而不能被提取的情况。在建库过程中，需对这两种情况进行区分，将正确的道路中心线提取出来，错误的要素剔除。
三是中心线要素冗余、重复。规划人员在用cad进行制图过程中，时常会产生重复要素，且不易被发现。在进行数据入库时，需对要素冗余、重复的情况进行处理，否则不能保证统计分析的正确性。可通过人工检查，或者通过arcgis的拓扑验证等方法，筛选出存在重复中心线的道路，并根据实际情况，删除冗余的道路中心线。
四是道路中心线节点密集情况。在建库过程中，可通过arcgis的概化功能将节点进行简化，以便于数据的展示，及提高数据库的性能。
3.1.2属性规则
根据应用需求，确定需要建设的道路属性：道路名称、道路等级、车道数、标准道路红线宽度。
道路名称主要针对主干路及以上的道路，名称包括道路的规划名称；道路等级、车道数应根据实际规划过程中，管理部门确定的道路标准进行属性入库；标准道路红线宽度由人工进行测量，测量对象为规划成果的道路红线，进行测量时，局部拓宽或收窄不考虑，一条道路只采用一个标准道路红线宽度；道路长度由arcgis软件自动计算生成。
3.2道路红线面
为达到统计道路红线面积、与地块实现无缝整合的目标，将道路红线进行构面。
构面时，可采用arcgis的“追踪”功能，沿道路红线进行构面，也可先将道路红线在交叉口处进行封闭处理，再采用“生成面”功能，进行构面。构面过程中，应在不同道路名称或不同道路等级的地方进行打断，同时尽量保持高等级道路红线面的连通，低等级道路红线面打断。
在提取道路红线图层数据，用于构面时，需注意以下情况：
一是分层错误。需人工判断道路的实际红线，根据真实的道路红线进行构面。
二是道路红线缺失。若能根据道路的其他要素补充道路红线的，可直接补充完整进行构面；若不能根据已知要素进行补充完善，需反馈给规划人员进行完善。
3.3公交站点
3.3.1制图规则
根据道路红线规划成果，提取划线式公交站点和港湾式公交站点，用点形式表达，并将点放在路缘石上。
3.3.2属性规则
公交站点的属性主要包括：类型、状态。
类型分为划线式和港湾式，直接根据红线成果进行区分。
状态包括：现状、规划。
3.4人行立体过街设施
3.4.1制图规则
根据道路红线规划成果，提取人行立体过街设施要素，用点形式表达。
3.4.2属性规则
人行立体过街设施的属性主要包括：类型、状态。
类型分为人行立体过街天桥和人行立体过街地道，直接根据红线成果确定的类型进行属性入库。
状态包括：现状、规划。
4结语
在建设交通规划数据库时，应先研究应用需求，明确如何入库才能实现既定的目标，再制定建库标准，最后才进行数据入库。重庆市道路红线规划涉及范围广、规划要素多，建设专题数据库的数据处理工作量很大，若不能根据目标，制定详细的建库规则，极易导致数据处理的返工，造成项目失败。应用需求是目标，建库规则是方法，有了目标、方法，工作就能顺利完成。
参考文献
广州船舶交通管理系统统计数据分析 篇3
【关键词】 海事;船舶交通管理系统;数据分析;安全建议;船舶流量
1 广州船舶交通管理系统(以下简称GZVTS)2010年3月份船舶交通流量及日常值班监控统计情况
本文所选的12条辖区门线将GZVTS辖区水域围成相对封闭的水域,全长约68 n mile,面积约412 ()2。
1.1 航经GZVTS报告门线的交通流量统计情况
借助管理信息系统(MIS)对航经GZVTS辖区门线的船舶动态记录数据进行统计,包括VTS系统内雷达自动跟踪数据、船舶自动识别系统(AIS)自动跟踪显示数据、VTS操作员的人工跟踪标识数据等。前两种数据由电脑自动记录,完全排除人为主观因素的影响,其准确性取决于系统雷达和AIS信号的强弱及其稳定性,准确率较高;后者由人工进行记录,其准确性取决于操作员的VTS值班经验和工作态度。统计时间为3月1―31日,周期为1 d,间隔为4 h,统计数据包括通过报告门线的船舶交通流总量、交通流进口量、交通流出口量和各时间间隔经过各报告门线的交通流峰值。 2010年3月份GZVTS报告门线的交通流量见表1。
表1 2010年3月份GZVTS报告门线交通流量艘次
1.2 GZVTS中心日常值班监控情况
GZVTS区域设置3个值班监控操作台,DP 1负责RLSE,RLTG,RLGW,RLLE,RLLW等5条报告线,面积约320 (n mile)2;DP 2负责RLLE,RLFZ,RLTP等3条报告线,面积约38 (n mile)2;DP 3负责RL75,RLD1,RLDJ,RLDG等 4条报告线,面积约60 (n mile)2。
2010年3月份,参与VTS值班的操作员共310人次,共接收船舶报告23 526艘次,跟踪船舶20 953艘次,信息提醒5 382次,应船方请求提供信息服务2 813次,重点监控船舶2 727艘次。
2 统计数据分析
2.1 船舶交通流量大
2010年3月份船舶交通总量达222 076艘次,平均每天经过报告门线的交通流量为7 166艘次。假设进出该辖区的船舶中有70%需2次经过辖区门线,则每天进入辖区的船舶约4 658艘次。
2.2 船舶报告量占交通流总量比例不高
船舶跟踪量占报告量比例为89.06%。一方面,由于VHF通话频密,信道拥堵,VTS操作员难以应对所有船舶报告并及时一一登记在册;另一方面,部分VTS操作员由于工作量较大产生消极意识而不作记录。
2.3 交通流密度分布不均衡
从统计数据来看,交通流密度在08:00―20:00时段达到高峰,为128 846艘次,20:00―08:00时段交通流密度相对较低,仅93 230艘次,二者相差35 616艘次。交通流量最大的门线是RLLE报告线(38 033艘次),交通流量最小的门线为RLD1报告线(5 172艘次),二者相差32 861艘次。
2.4 与2009年3月份统计数据的比较
2.4.1 交通流量基本持平
2009年3月份的交通总量为220 276艘次,2010年3月份的交通总量为222 076艘次,增加1 800艘次。从统计数据看,主要是航经RLLW,RLTP,RLDJ,RLGW,RLDS,RLTG等报告线的交通流量有所增加,其中航经RLLW报告线的交通流量从2009年3月份的艘次增加到2010年3月份的艘次,增加艘次;航经RLSE,RLLE,RLFZ,RLDG,RLD1,RL75等报告线的交通流量有所减小,其中航经RLD1报告线的交通流量下降最多,达艘次。究其原因,可能由于黄埔大桥对雷达信号的影响使航经RLD1报告线的船舶视频回波不稳定,导致VTS系统不能及时捕捉船舶信号。
2.4.2 船舶报告量、跟踪数明显减少,信息服务次数有所下降
2009年3月份船舶报告量为艘次,跟踪船舶艘次,重点监控船舶艘次,信息提醒次,信息服务次;2010年3月份船舶报告量减少艘次,船舶跟踪数减少艘次,信息提醒减少次,信息服务减少次,重点监控船舶基本持平。
一方面,利用MIS记录船舶动态信息的过程比较繁琐,部分VTS操作员对统计数据资料不够重视,只记录其认为比较重要的部分信息;另一方面,由于VTS操作员值班工作量较大,因此偏重于重点船舶的监管和船舶监控提醒等与水域安全直接相关的工作,并不记录全部事项,因此造成数据量明显下降。
3 安全管理改进建议
3.1 完善VTS系统
尽快优化雷达、AIS等基站管网的布局,大力引进或开发先进软件,提高VTS系统性能,保证VTS数据的准确性。
3.2 加强对小型船舶动态的现场监管
由于VTS设备性能的局限性,VTS系统对于大型船舶的管理基本到位,但对小型船舶的监管效率不高。从近期辖区事故险情统计数据看,小型船舶比较容易发生险情,加强对这类船舶动态的现场监管很有必要。
3.3 扩大配制AIS设备的船舶范围
从日常值班情况看,多艘船舶同一时刻经过报告门线的情况时有出现,此时VTS值班员很难做到对未配制AIS设备的船舶进行准确的跟踪识别。由于目前设备性能存在一定的局限性,对中小型船舶的跟踪识别容易丢失,也就不能给中小型船舶提供及时的信息服务,VTS功能的发挥因此受到严重影响。
3.4 改进系统记录的方式、方法
目前,GZVTS采用的MIS系统程序较为繁琐,一些名词术语不易理解归类。建议自主开发或引进新的记录模式,增强系统自动记录功能,减少人工记录工作量,提高统计数据的全面性、准确性。
3.5 增设VTS监控操作台,增加VTS操作员,优化人均监控区域
GZVTS现有VTS操作员20人,个人监控区域最大达320 (n mile)2,最小约40 (n mile)2;个人监控船舶交通流量最大达艘次/d,最小不低于200艘次/d。过大的监管区域不易于VTS监控操作台监控画面的设置及监管区域整体性的保持,频繁切换监控画面不但耗费不必要的时间而且影响VTS操作员的监控连续性。安全责任是VTS操作员最大的压力源之一,而过大的工作量容易引起操作员水平发挥失常,使其监管服务的及时性、有效性得不到保证。近期险情主要发生在主航道以外的水域,而目前值班人员的配置只能满足对重点水域的重点监管,主航道以外水域往往成为监管的非重点水域,且在航道外航行的船舶绝大多数是没有跟踪标识的小型船舶,容易被疏忽。因此,应增设VTS监控操作台及操作员,优化人均监控区域。
4 结 语
交通数据库系统 篇4
轨道交通AFC系统采用三级组网、六层架构,包含自动售检票清算管理中心系统(ACCS-Automatic Fare Collection Clearing Management Center System)、线路中央计算机管理中心(L C-L i n e C o m p u t e r Management Center)、车站计算机管理系统(SC-Station Computer Management Center)、车站终端设备、车票读写器和票卡。从信息技术层面看,AFC系统也是一个数据处理系统,其数据流具有如图1所示特点。
系统设备通过网络将有关数据上传到SC和LC,同时接受SC和LC的指令、系统参数及软件更新等下传数据。SC和LC对所收集的数据按类型及用途进行实时或批量地处理,以满足系统监控、运营管理及决策分析的需求,所以确保数据采集和处理过程的安全、完整、准确尤为重要。
2 数据收集
2.1 数据类型
SC和LC所收集的数据主要包括设备状态数据、设备寄存器数据、设备交易数据、收益及设备维护数据等。
2.1.1 设备状态数据
包括设备运行产生的所有运作模式、操作模式、各部件状态、报警及故障等数据。数据在设备状态变化时上传,及按照系统参数设置的查询频率或即时查询设备的状态数据。
2.1.2 设备寄存器数据
包括设备中不同票种在不同类型交易的金额及次数、现金模块处理现金的金额及次数、车票模块处理车票的张数、各种系统收益及维修统计等数据。数据按照系统参数设置的查询频率自动进行查询,其频率最高为1分钟。同时,设备车票及收益处理监控状态变化时自动上传寄存器数据,例如设备登录、注销、钱箱及票箱更换等。
2.1.3 设备交易数据
包括各种车站设备对各种车票的赋值、发售、充值、扣值、进出站、更新、替换、退款等各种交易类型的数据。
2.1.4 车站收益管理及设备维护管理数据
包括设备班次审核、钱箱及票箱审核、车站收益核算、收益平衡及收益统计、设备维修管理日志及维修统计等数据。
2.2 数据传输方式
2.2.1 在线数据传输
LC在线采集系统设备所上传的数据,车站设备通过SC上传数据。在SC通信故障情况下,LC通过车站网络直接采集车站设备的数据。
数据接收方在进行数据接收时,在确认成功接收前确保对数据已经成功保存,不会发生已确认成功接收,但又未成功保存,而导致数据丢失的现象。
如图2所示,数据接收方通过返回应答给数据发送方,来确认其已经收到数据。数据发送方在收到应答后,停止对该数据的重发。若在规定的重发时间内没有收到应答,将再次发送该数据。
2.2.2 离线数据传输
系统设备在与SC或LC通信中断的情况下,工作在离线运行模式下。在该运行模式下,设备依据本地保存的系统参数运行,设备产生的交易数据将保存在本地的存储介质上。当交易数据累积到无法再保存时,将自动转为暂停服务模式,从而停止对外服务,不再产生新的交易数据,或删除最不重要或最旧的数据。
此时,LC和SC通过备份介质(如移动硬盘)离线采集数据。先从数据来源节点将要传输的数据导出到备份介质上,再通过数据接收节点提供的本地数据传输接口,将需上传的数据导入到数据接收节点。数据接收节点在导入数据时将对数据进行检查,剔除重复数据。
2.2.3 在线数据恢复
当SC和LC通信中断时,SC工作在“孤岛”运行模式下,将继续自动采集并保存数据。当通信恢复后会将所有数据自动上传至LC。LC对所有上传的数据进行重复性检查,剔除重复记录,保证数据不重复。
另一种在线数据恢复功能是数据接收方主动索取数据。例如:LC能够从SC得到数据保存期内所需的数据。若LC发现数据缺失,可通过向SC主动索取数据的方式,促使SC再次发送其保存的数据。
LC在进行数据采集时,将检查收到的数据是否是重复的数据,通过在数据库表设置唯一主键的方式实现的。若数据重复,会发生因主键冲突插不进库的情况,可有效剔除被重复发送的数据。
3 数据处理
系统对所收集的数据按类型及用途进行实时或批量地处理,以满足运行、票务、财务、维修的需求。
为确保数据完整、准确、快速处理,至少对数据进行以下的处理:
1)验证数据的完整性及合法性;
2)检查数据的连续性;
3)保存数据,添加/更新相关的系统数据库。
3.1 验证数据的完整性及合法性
在传输数据时,对数据进行加密,以确保数据传送过程的安全,并采用MAC验证确保数据传送的完整性,采用TAC验证确保数据的合法性。
3.1.1 MAC验证
报文来源正确性鉴别(MAC-Message Authentication Code)是一种判别报文来源是否正确,以及报文在发送途中是否被篡改的算法。发送方按规定的加密算法产生MAC,随消息一起发往接收方;接收方在收到消息后,按相同的算法鉴别消息来源正确性。当且仅当鉴别结果正常时,才进行消息的业务处理。
3.1.2 TAC验证
交易合法性验证(TAC-Transaction Authentication Code)是一种类似于MAC验证的判别报文完整性的算法。与MAC验证的主要区别是:MAC验证侧重于通信层的报文传输完整性验证,而TAC验证则侧重于应用层的交易合法性验证,防止交易信息被伪造和篡改。交易记录生成方按规定的加密算法产生TAC,随交易记录一起发送出去;在一些中间节点的转发过程中,TAC保持不变。最终的交易接收方在收到消息后,按相同的算法鉴别交易信息的合法性。当且仅当鉴别结果正常时,才认为此交易记录是合法的,继而进行交易的业务处理。如果交易未通过TAC验证,则被列为可疑交易,不参与正常的清算过程。
3.2 检查数据的连续性
系统检查各类数据的连续性,以防止数据的异常、遗漏、重复、延迟及伪造。对于累计性数据在发生前后数据异常情况时,如数值突变、回零等,则能及时处理;对于遗漏的数据,系统向设备查询;对于延迟数据则即时进行数据统计及计算更新;对于重复及伪造数据则即时排除。其连续性的跟踪方式如检查票卡交易序号、设备交易序号、设备交易累计、卡余额等。
3.2.1 票卡交易序号
票卡在从厂商购买回来后,首先必须经过系统初始化后,才能使用。在初始化过程中,将对票卡内存储区进行编码,编码过程中很重要的一步就是在票卡存储空间中建立票卡钱包,而票卡交易序号与票卡钱包的操作是密切相关的。
初始化完成后,票卡交易序号被赋为0值,在票卡投入运营后,发生对票卡钱包操作时,设备将读取此票卡交易序号的当前值,在对其值加一后写入票卡中。票卡交易序号在票卡的生命周期内,始终为连续增长的。票卡交易序号满足以下公式:
交易后票卡交易序号=交易前票卡交易序号+1
如图3所示,票卡在进行出售、消费、充值和回收/退卡交易时,票卡交易序号都将加一,而在初始化过程中,如果是新卡初始化,则对票卡交易序号赋0值,如果是对回收卡的初始化,则只初始化其它数据项,而票卡交易序号则保持原有的数值。
通过对票卡交易序号的连续性处理,在进行票务分析时,就能通过票卡交易序号对卡的流通过程进行全程跟踪。虽然通过票卡交易的时间也能对票卡交易过程进行分析,但由于系统中的大部分设备是允许脱机运行的,交易的时间是从终端设备内部时钟获取的,由于终端设备时钟精度可能参差不齐,经常会出现误差,也不可能进行频繁的时钟同步,故通过交易时间来跟踪票卡的运营是不准确的。而引入票卡交易序号后,则可以较好的解决这一问题。
另一方面,如果在通过票卡交易序号对交易数据进行连续性检查时,如果出现某张票卡的交易序号不连续,则可以认为存在以下几种可能:
1)票卡交易未上传
对于某一张卡来说,设备上传交易的时间是可能是无序的,即先发生交易的设备可能比后发生交易的设备后上传数据,造成票卡交易序号较大的交易比票卡交易序号较小的交易先上传。
对于卡交易未上传的情况,如果在保障设备都能顺利上传数据的情况下,不连续的情况将在相对当前日期的前一段时间内(如系统要求设备在7天内上传数据)得到消除,即7天前系统内各卡的交易序号将连续,但不能要求当前卡交易序号必须连续,因为这种连续性是有一定滞后的。
2)卡交易丢失
如果终端设备上存储的交易数据出现丢失的情况,在该设备上发生交易而交易未上传的卡将出现卡交易序号不连续的现象。
如果某卡当前交易序号与当前连续的交易序号相差较大,且交易发生的时间也相差较大,则基本可判定该卡的交易出现丢失。
3)交易重复上传
如果设备重复上传交易记录,则会出现卡交易序号重复的情况。如果出现交易重复,系统将丢弃这些交易记录。
4)卡交易不合法
如果出现伪造交易或设备由于故障写错了卡或交易记录时,卡交易序号将不连续。如果卡交易序号出现重复或跳跃性增长或减少时,将此卡加入黑名单,控制其使用,或与持卡人联系后收回卡后进行分析,以防止错误的扩大化。
卡交易序号也可使系统统计票卡内钱包使用次数的工作得到简化,因为卡交易序号的最大值即卡钱包的操作次数。对于系统资金的稽核具有很好的辅助作用。
3.2.2 设备交易序号
设备交易序号是由设备进行维护的不断增长的序列号,每发生一次交易,此交易序号将被加一。设备交易序号的初始化是在设备投入运营前被置0值的。
设备交易序号足以下公式:
交易后设备交易序号=交易前设备交易序号+1
同通过交易时间来跟踪票卡流通过程会出现不准确的情况一样,通过交易时间来跟踪终端设备交易过程也会出现不准确的情况,而通过引入设备交易序号,即可较好地解决这一问题,连续的设备交易序号,在一定程度上反映了设备在连续正常工作。
在以下几种情况下可能会出现设备交易序号不连续的情况:
1)设备交易丢失
设备中存储的数据由于故障而丢失时,设备交易序号将不连续。在确认该设备上的数据已全部上传后而发现缺失了部分序号(同时设备交易累计不连续)时,即可判定该设备出现交易丢失,将通过其它方式进行数据的恢复。
2)设备交易重复
当设备重复发送交易记录时,设备交易序号会出现重复,系统在接收到重复交易后将会丢弃这些记录。
3)设备被完全初始化
设备因故障进行维修(如更换存储器)后,重新初始化时将会清除设备交易序号。
4)设备异常或交易不合法
如果设备处理票卡出现错误、交易为伪造交易或数据传输错误这些情况时,设备交易序号将不连续。
设备交易序号是对设备交易进行稽核的一种手段,通过对其连续性的分析可对系统内设备的运营情况进行很好的监督,及时发现和纠正设备异常。
3.2.3 设备交易累计
设备交易累计是终端设备对票卡钱包增加或减少额度的历史累计值。对于单一消费终端,累计值为发生交易的票卡钱包的扣款额的累计,通常为负值;对于单一充值类终端,累计值为发生交易的票卡钱包增加额的累计,通常为正值;对于既可消费又可充值的终端,累计值则可正可负。
发生交易时,设备交易累计满足以下公式:
交易后设备交易累计=交易前设备交易累计+增值额或
交易后设备交易累计=交易前设备交易累计-扣款额
通过对交易记录的交易金额和设备交易累计这两项数据的逻辑关系分析,可以对交易的合法性和正确性进行稽核。当某设备的连续两笔交易(连续性通过设备交易序号的连续性来判断)不满足以上公式时,即可判定交易过程中出现异常,需进一步分析错误产生的原因,防止出现伪造交易或排除设备故障。
设备交易累计出现不连续的原因和相应的处理方法与设备交易序号不连续出现的原因和处理一致。
3.2.4 卡余额
卡余额在票卡内和系统内都将保存,在正常情况下,卡余额满足以下公式:
交易后卡余额=交易前卡余额+钱包变化额(增加时为正,减少时为负)
通过对交易记录的交易金额和卡余额这两项数据的逻辑关系分析,可以对交易的合法性和正确性进行稽核。当某票卡的连续两笔交易(连续性通过票卡交易序号的连续性来判断)不满足以上公式时,即可判定交易过程中出现异常,需进一步分析错误产生的原因,防止出现伪造交易、排除设备或卡故障。
卡余额交易累计出现不连续的原因和相应的处理方法与票卡交易序号不连续出现的原因和处理一致。
3.3 数据保存
系统即时保存所收集的数据,添加/更新相关的系统数据库,并对原始数据不进行任何修改或删除。
4 结语
综上所述,3种数据传输方式可以有效地确保数据采集过程的连续性;采用MAC验证可以有效地确保数据传送的完整性,采用TAC验证可以有效地确保交易数据的合法性;综合采用票卡交易序号、设备交易序号、设备交易累计、卡余额4种方案可以相互补充,互相验证,可以有效地解决数据的异常、遗漏、重复、延迟及伪造,确保数据的安全、完整、准确。
参考文献
[1]高朝晖,何铁军,张宁.轨道交通线网AFC系统黑名单管理[J].都市快轨交通.2010,23(1):89-92.
[2]王健,张宁,毛建,等.南京地铁AFC系统网络化建设中面临的问题初探[J].轨道交通.2006(9):48-50.
[3]张宁,房坚,王健.南京地铁AFC系统建设思路分析[J].金卡工程.2005(1):59-61.
[4]申香梅,廖东玲.深圳地铁自动售检票系统方案[J].都市快轨交通.2000(1):32-34.
[5]GB50157―2003地铁设计规范[S].北京:中国计划出版社.2003.
大数据理论指导交通数据分析的方法 篇5
近期成立的深圳市综合交通运行指挥中心囊括深圳全市24个交通信息化系统和海量的交通基础数据，上述问题应该也是其重点的研究方向。
抛砖引玉：
分析案例1：结合公交车GPS数据、乘客刷卡信息等数据，能够获取每辆公交车每个站点停车时间、上下车乘客数量、乘客精细时空轨迹等，再此基础上应该可以做“公交车线路、站点、发车频次优化”、“典型居住区和就业地的通勤出行分析”等分析。
分析案例2：结合RFID、GPS等数据，能够获取车辆精细化时空轨迹信息，能够对行车辆行驶轨迹、路段行程时间可靠性、OD分布(起点-终点)等进行数据分析，应该能替代部分传统交通规划和交通需求分析的内容，理论上应该更加实时可靠。
用大数据改善城市交通排放 篇6
6月8日，在北京召开的第二届中美气候智慧型/低碳城市峰会上，能源与交通创新中心（iCET）等多家机构联合倡议，用大数据研究来开发一套量化可持续性环境影响的全球标准——“可测量、可报告、可核实”标准（以下简称“MRV标准”），以推动政府和企业建立量化监测体系。
此前，iCET在成都的研究时发现，应用实时数据计算一次出行的碳排放要比传统的推算结果高出44%（普通路况下）和78%（高峰时段下）。宏观来看，成都每天的交通出行碳排放大约为17500吨，比传统方法（测试工况下）估算的结果（11000吨）高出59%。这样明显的差距更加说明了建立一套基于实时数据的MRV标准的重要性。
交通领域亟需MRV标准
事实上，由于数据缺失及技术瓶颈，交通领域一直缺少一套可落地实施的MRV标准。全球行业权威标准机构国际汽车工程师协会（SAE International）的主席古耐特·奥格（Cuneyt Oge）曾表示：“在信息化时代下，我们一定要充分应用大数据等尖端技术来应对气候变化的挑战。MRV是协助政策制定者来更精准地评估排放标准的合规性的关键性标准，也是推进碳排放问责制度建立的核心因素。”
随着大数据、云算法、车辆互联等新技术的发展，世界第一次有机会去实时地获取和核实交通出行数据，并可通过数据来动态地反映一个城市千变万化的交通脉络。例如，打车软件积累的出行大数据资源可以为分析城市交通复杂的供需关系提供数据源。
而对于中国的碳交易市场而言，加强碳排放的监管工作非常重要。从企业到政府之间的碳排放报告、监测、核查过程中（MRV），第三方机构担当着重要的作用，可以降低政府对减排行动的监管成本，提高政府对碳排放监管工作的效率。同时，可以提高政府对碳排放监管的透明度和公信力。
iCET的呼吁
通过在成都开展的试点项目，iCET示范了采用精准、可核实的事实数据进行碳排放量化以及全价值链分析的应用前景，并且探索了“拼车”这一创新交通模式的潜在影响。在6月8日的第二届中美气候智慧型/低碳城市峰会上，能源与交通创新中心（iCET）还举办了“大数据助力城市交通可持续发展”新闻发布会，宣布将联合多家机构组成研究联盟，同时，能源与交通创新中心（iCET）呼吁通过各个机构的共同努力，开发并应用MRV标准来应对交通领域的气候变化问题。包括中国发展与改革委员会能源所和中国优步在内的机构共同参与了此次试点项目，试点项目由美国国家地理学会环境与水保护基金提供资金支持。
该研究联盟正在开发的Live-Cycle方法论是一套基于全球价值链和大数据分析应用的方法论框架，将用于支撑MRV标准的开发，而未来的MRV标准可以建立一个透明的问责监督机制去推动价值链上的各方来履行各自的环境义务，应对气候变化带来的挑战。
全球交通领域的主要多边合作平台“经济合作和发展组织-国际交通论坛（OECD-ITF）”的首席研究员斯蒂芬.帕金森（Stephen Perkins） 表示：“ITF的模型所得出的结果和Live-Cycle试点项目的结果基本吻合，ITF认同，包括拼车在内的共享交通创新模式，具有减少排放的潜力。基于MRV的原则来监控这些举措对于路况的影响，并了解所有车辆的真实运行情况对于减排政策的有效实施是个至关重要的因素。”
交通碳排放的监管
同时，交通领域的大数据也能够更直观地去反映城市居民的乘用车出行需求。研究结果显示，80%的交通出行具有较高的重合度（起点和终点相同），即这些出行具有拼车的条件。通过进行数据模型的仿真模拟，iCET发现，如果通过拼车来提升20%的车辆运载能力的利用率，那么成都市整体的交通碳排放可以降低28%；如果利用率可以提高至60%，那么成都的堵车情况将会明显缓解，同时70%的交通碳排放可以被避免。对此，来自中国优步研究院的负责人聂育仁表示，优步的内部研究也得到过和此次试点项目类似的结果。“自2015年7月以来，优步在成都提供的拼车服务减少了总计5000万公里的行驶里程以及约14000吨的碳排放。我们支持共享经济及拼车的发展，同时，我们很荣幸成为此次公私合作研究联盟中的一员，通过合作共研来促进公共事业的发展。”
iCET的创始人和执行主任安锋博士强调，“这次的公私合作项目是第一次应用大数据研究来推动环境影响问责监督机制的建立。为了有效地达成可持续性发展目标，我们需要务实的可持续性行动。而真实的可持续性行动需要有能够量化可持续性的MRV标准的支撑，并需要在信息透明环境下通过公私合作机制来实现。这也是我们开发这个基于大数据的MRV标准的初衷和美好愿景。”
背景新闻：
2016年6月8日，能源与交通创新中心（iCET）在第二届中美气候智慧型/低碳城市峰会承办了“低碳交通大变革”分论坛，探讨在新时代、新驱动背景下，寻求如何利用新技术、新模式与新机制来加速交通低碳化、清洁化进程，来自中美城市市长、各级政府交通主管领导，研究机构、汽车企业、互联网出行平台等方面，共计130多位行业领袖参会。本次分论坛上，美国驻华大使馆首席商务参赞Val Huston先生，美国加州能源委员会主席Robert Weisenmiller先生、美国加州空气资源委员会执行主任Richard Corey先生、中国电动汽车百人会理事长陈清泰先生、中国汽车工业协会常务副会长兼秘书长董扬先生、能源与交通创新中心执行主任安锋博士，以及美国波特兰市、中国北京市、贵州市、济源市等城市市长或高级别官员分享了低碳交通发展经验，特斯拉、比亚迪、滴滴、优步、高德等创新型企业高管就中美两国汽车电动化、智能化、互联化技术创新，共享出行模式、大数据应用与互联交通等话题进行了探讨。
交通数据库系统 篇7
关键词：轨道交通,综合监控,数据规模,系统性能
1 概述
在城市轨道交通综合监控系统的建设过程中, 应对系统的数据规模和系统性能做详细的测算和分析, 以使软硬件配置满足系统要求、满足扩容要求, 并且不产生浪费。
2 系统规模
ISCS系统设计应充分考虑线路ISCS的规模并完全响应要求。ISCS的系统功能主要由系统软件的总容量决定。ISCS软件平台整体结构应具有灵活性、可扩展性、稳定性的特点。凭借整体结构的扩展能力, 系统应可在未来增加服务器的数量, 使系统升级到更高的点数。为了保证系统的性能和将来扩充, 服务器、网络和软件平台的处理能力在上述基础上预留30%以上的裕量。集成系统实时向ISCS系统传送数据, ISCS系统应支持查询和事件触发方式与集成系统交换数据。
3 性能分析
3.1 现场设备控制时间
现场设备的控制时间指从操作员发出控制和指令操作开始, 到控制和指令操作条件检查返回为止的时间, 包括控制和指令传送到FEP、进行处理和激活控制点或信息的时间。
中心对现场设备的控制相应信息返回时间不应大于4s。从中心控制命令发出, 到现场设备开始动作的时间不应大于2s。车站的现场设备的控制时间不应大于2s。从车站控制命令发出, 到现场设备开始动作的时间不应大于1s。当一个控制命令执行出错时, ISCS系统应能及时作出提示, 并且不能影响系统其它功能。
3.2 系统可用性
ISCS系统是一个大型的分层分布式计算机监控系统, 系统的有效性一方面依赖于系统充分地无故障正常工作, 另一方面依靠系统发生故障时尽快地修复系统恢复正常。按照可靠性原理, ISCS是一个可修复系统, 可修复系统的系统可靠性用有效性或有效度A指标来表示。系统有效度也就是系统有效性定义为系统考核期内系统正常工作时间与考核期全部时间之比。
系统有效性A按如下公式计算:
式中:MTBF为系统平均故障间隔时间;MTTR为系统平均修复时间, 反映了系统的有效工作时间的统计值、后者反映了系统修复恢复正常的时间统计值。
下图说明了MTBF与MTTR的含义及关系, 也说明了MTBF和MTTR的统计性质。
由图可见:
(2)
(3) 一个系统的MTBF和MTTR是统计计算得出, 不是由确定性公式计算出来的。正像可靠性指标A是一个概率统计值一样, MTBF和MTTR也是一个概率统计值。
由 (1) 式可见, 提高系统有效度 (可靠性) 的方法是尽可能提高MTBF值和降低MTTR时间。
在分析系统有效性时, 关键是确定系统在考核期内的正常工作时间和系统故障时间 (总时间为两者之和) 。因此, ISCS可用性计算必须统计计算关键设备的主要故障时间。
ISCS中, 每个子系统的内部设备可以划分为关键设备和非关键设备。如果一个设备故障影响到整个系统的运行, 它被视为关键设备。例如, ISCS服务器是关键设备, 而打印机则是非关键设备。因为服务器故障会导致系统崩溃 (在第二台服务器已故障的前提下) , 但如果打印机发生故障, 仅仅会影响打印功能。
每个设备故障分为主要故障和次要故障。当故障影响到系统的主要功能, 则此故障视为主要故障。比如, 对服务器而言, 磁盘故障视为主要故障, 但是, DVD光驱故障被视为次要故障。
在对系统进行有效性考核时, 必须考虑以上因素。按照关键设备的主要故障发生的具体情况判定全系统故障从而来统计计算系统的MTBF和MTTR的值。系统有效性的考核是一个科学的过程, 在考核期内 (例如, 连续考核数个月或半年) 记录关键设备的主要故障并记录考核结果, 统计出MTBF与MTTR的值。
⑴关键设备的可靠性指标。以苏州地铁4号线为例, 在本项目中, 主要设备可靠性指标如下表所示:
⑵MTBF计算
ISCS工作站、历史服务器、实时服务器、交换机、FEP都采用完全冗余配置 (并联) , 根据并联系统MTBF计算公式, 双份冗余设备的MTBF是单个设备MTBF值的平方, 即
本系统历史服务器配置了磁盘阵列, 冗余历史服务器和磁盘阵列组成了串联的服务器—磁盘阵列系统。其MTBF值为:
历史服务器—磁盘阵列、实时服务器、网管服务器组成了一个服务器权联系统;其中网管服务器仅对网管工作站提供少量数据, 而实时/历史服务器则负责为工作站提供大量的数据, 所以网管服务器的权重显然远低于实时/历史服务器, 故可忽略, 服务器权联系统MTBF值计算如下:
所有的调度员工作站组成了一个工作站权联系统。由于工作站的型号统一, 因此
工作站权联系统、服务器权联系统、冗余交换机、冗余FEP组成了一个串联的ISCS综合监控系统, 整个ISCS综合监控系统的MTBF计算如下:
⑶MTTR计算
ISCS综合信息系统的平均修复时间MTTR是按系统内各个设备失效率进行加权平均的平均值。
根据MTTR计算公式
首先计算ISCS综合监控系统各成员的故障率λ, 即各成员的MTTR权重:
经计算,
据可用率公式:
3.3 系统可靠性
系统服务器、前端处理器的主机、备机的切换时间不大于3秒钟, 切换时间从软件或硬件被检测出故障开始算起, 到ISCS完全可用为止。
数据库服务器的主机、备机的切换时间不大于15s。
缓存区已满不引起ISCS的崩溃。
任何网络设备, 包括操作员工作站、服务器、交换机等, 如果发生单点故障, 不影响ISCS的正常工作。
对ISCS进行的可靠性设计主要表现在对系统关键设备的冗余设计上。在ISCS中, 对系统的三级网络 (MNS、中央监控网、车站监控网、现场总线) 、中央服务器、车站服务器、FEP、操作员工作站、环境与设备监控子系统的PLC进行了双重冗余设计。
网络及主要控制器都采取了双重冗余, 极大地提供了系统的可靠性。
按照现代可靠性理论, 关于双重冗余系统的可靠性计算分析如下:
若一个单系统未采取双重冗余时的故障率为λ, 修复率为μ, 按照可靠性理论:
可修复系统的运行过程是一个由正常工作过程到故障过程, 经过修复恢复正常工作过程的不断反复的随机过程, 此随机过程可近似为一个马尔柯夫随机过程 (平稳随机过程) 。采用平稳随机过程状态转移矩阵的分析方法, 可以计算出正常状态和故障状态的概率, 从而计算出各个可靠性指标。系统冗余配置时, 其随机过程的状态转移可以用马尔柯夫图表示。
图中S0为主备系统都正常状态, S1为一个系统故障状态, S2为两个系统都故障状态。按照马尔柯夫过程的随机状态转移原理, 其状态转移矩阵为:
其中P0为冗余系统都正常时的概率;P1为主系统故障备用系统正常的概率;P2为主备系统都故障的概率,
且
式中:
P0为两冗余系统都正常的概率
P1为冗余系统其中一个正常, 一个故障的概率
P2为两个冗余系统都故障的概率
系统正常得概率为P0+P1, 即系统可用度:
与单系统相比, 冗余系统可靠度大大提高, 一般有效度可提高一个“数量级”, 即如果单系统A=90%, 则双重冗余系统的A=99%。单系统A=99%, 双重冗余系统的A=99.9%。
以苏州4号线为例, ISCS的高可靠性解决方案如下:
⑴冗余、热备中央服务器:当主服务器发生故障 (包括软件或硬件故障) , 备份服务器自动接管主服务器功能。服务器切换时, 没有数据丢失。
⑵冗余系统网络:系统网络上每台关键设备和两个网络都有连接, 避免一个网络故障, 影响数据通信。当一台交换机故障时, 另一台交换机根据网络拓扑, 动态切换到网络中最短的路径。
⑶冗余、热备车站服务器:当主服务器发生故障 (包括软件或硬件故障) , 备份服务器自动接管主服务器功能。
软件开发和实施过程进行严格质量控制, 采用有效的错误分析和跟踪方法, 确保每一个提交的软件部件都通过仔细的测试和代码分析;
以上这些方法在多个领域的监控系统都已经得到了成功应用, 确保了系统连续运营。
3.4 系统扩展性
鉴于苏州市轨道交通建设处于高速发展阶段, 多条线路同时建设, 相继投入运营。因此要求综合监控系统具有良好的扩展性, 综合监控系统具有如下特点:
⑴系统设备模块化, 软件组件化, 可以实现灵活拼装。
⑵硬件配置和数据组织形式以车站综合监控系统为单位, 一个车站就是一个模块, 是基础的数据源。车站综合监控系统可以向多个中心同时提供数据服务, 支持多中心结构。
⑶采用通用以太网设备和开放的通讯协议, 网络系统扩展性好, 允许平滑扩展。
⑷采用中间件技术, 对于应用软件屏蔽具体的物理连接和位置, 对于任何数据对象访问, 均可以用线路名-站名-点名逐级检索, 每个数据对象的命名在整个苏州轨道交通是唯一的。
考虑为4号线及支线延伸线预留一定的条件, 建议方案如下:
⑴增加新站:单独调试新站的车站ISCS, 在完成后, 将该站本地ISCS网络连入骨干网, 将该站数据库配置组态数据加入控制中心数据库, 在中心操作站增加新站画面。
⑵增加换乘站:修改数据库, 增加被监控设备的组态配置数据, 通过开放的数据接口获得新建部分的数据, 同时向另一条线路的ISCS提供既有系统的信息, 在车站和中心增加部分画面。
ISCS系统支持服务器群集 (CLUSTER) 的扩展方式, 在现有服务器性能不能满足系统扩展需要时, 能够通过配置新的服务器, 分布式管理新建车站或其他扩展要求, 由多组服务器共同完成ISCS的监控功能。新旧服务器可以是不同厂家和型号的设备, 通过CORBA实现异构分布式数据环境下的远程对象调用, 满足系统扩展性的要求。
系统软件提供多种开放的协议, 第三方厂商可以通过网络接口, 在得到授权后, 获取ISCS数据。系统软件还能够增加各种数据接口, 实现与其他系统的数据共享。
参考文献
[1]魏晓东.地铁综合监控系统建设关键问题分析[J].现代城市轨道交通.2009 (06) .
[2]黄昱旻.地铁综合监控系统结构研究[J].现代城市轨道交通.2009 (04) .
[3]张森, 蔡昌俊, 何正友, 于敏.地铁综合监控系统可靠性分析与数据管理软件研制[J].交通运输工程与信息学报.2007 (04) .
交通数据库系统 篇8
综合监控系统是实现城市轨道交通自动化调度管理的重要工具, 也是当今城市轨道交通监控系统的主要发展方向。设置综合监控系统的目的, 就是为了增强城市轨道交通系统指挥调度的统一性、灵活性和系统间的协调运作能力, 因而综合监控系统性能的优劣直接关系到它是否能在城市轨道交通运营管理中发挥应有的效能和能否满足城市轨道交通运营管理的需要。综合监控系统数据库部署及服务器配置方案是影响综合监控系统性能及投资的关键因素[1]。本文依据综合监控系统的发展趋势及多年的设计和工程经验对数据库部署和服务器配置方案进行归纳和总结, 为综合监控系统的工程设计提供设计思路和方法。
1 数据库部署方案
综合监控系统根据运营管理模式、采集信息的处理方式以及中心级存储和管理数据量的大小, 在数据库部署上可分为以下四种方案。
方案一, 中心集中与站点分布的数据库部署方案:在中心级设置全局实时数据库和历史数据库, 将车站级的所有联网子系统的全部数据实时地采集到中心级来进行统一的管理和控制[1,2]。由于数据量的庞大, 处理复杂, 需要分别设置实时数据库和历史数据库, 以便监视和控制全线所有监控对象, 实时反映现场状态并进行及时的响应和存储。车站级仅设实时数据库, 仅用于监控, 负担本站所辖范围内的数据采集、报警分析、运算控制、事件记录等事务。车站不设历史数据库, 数据以文件形式存储, 历史数据的存储、整理、统计、分析等数据管理工作不在车站级实现。如果某个站点需要查询相关数据, 则必须通过综合监控系统主干网络来远程调取中央全局历史数据库中的相关数据, 传输网络的依赖性较大。
该方案有利于数据的多重保护和历史数据的集中管理, 但需依靠综合监控的骨干网实现历史数据的查询, 对网络具有一定依赖性, 同时要求骨干网具有较大的带宽, 且系统投资较大。适合车站规模大且站点数目较多的线路。该方案数据库部署及数据流如图1所示。
方案二, 中心数据库集中部署方案:仅在综合监控系统中心级设置全局的实时数据库和历史数据库, 在车站不设置数据库, 只设置网络设备和车站终端工作站等[1,2]。全线所有站点的被监控对象的实时监控数据都集中传送到中心来进行处理、存储和管理。如果某个站点需要查询相关数据, 则必须通过综合监控系统主干网络来远程调取中央全局数据库中的相关数据。
该方案的主要特点是所有数据集中存储在控制中心, 各站点的应用通过骨干网与中心数据库通信, 保证了每个终端应用使用的都是同一信息。在该方式下, 实现数据备份及安全防护比较容易。但该方案由于所有车站应用均需要访问中心数据库, 增加了对传输网络的依赖性, 系统处理速度稍慢。另外, 如果用户有新的应用需求, 在集中式结构上满足这些需要难度较大, 因为每个用户的应用程序和资源都必须单独设置, 而让这些应用程序和资源都在同一套中央集中式服务器上操作, 使得系统效率不高。该方案对服务器、软件平台及传输网络的依赖性都较大, 适合车站规模小且站点数目较少的线路。该方案数据库部署及数据流如图2所示。
方案三, 站点分布的数据库部署方案:综合监控系统不设置全局性数据库, 车站级数据库作为数据收集、处理和保存的核心[1,2];在日常工作期间, 如果车站工作站需要查询本区域范围内的数据, 只需在本地数据库调取相关数据。如果网络上某个节点需要查询其他站点范围内的数据, 则需要通过网络调取相应站点数据库中的数据。控制中心可作为一个特殊站点考虑, 控制中心的数据库规模与车站相当。此外, 由于电力监控系统对实时响应要求较高, 且站间联系较为紧密, 因此需要将全线SCADA数据存入中心数据库, 以利于对全线的变电所综合自动化系统信息的调用访问和显示, 也便于控制中心电力调度人员对整个地铁供电系统进行统一调度。
该方案对传输网络的依赖较小, 切换实时响应高, 调试方便, 对软件要求低, 配置也较低, 但不利于数据的集中管理及备份操作。且需要增加站点服务器的存储成本。适合车站规模大且站点数目较少的线路。该方案数据库部署及数据流如图3所示。
方案四:混合数据库部署方案:该方案可视为方案一的延伸, 在方案一两层的架构下增加集中站数据库部署层次, 以实现车站分为集中站和卫星站的管理模式[1,2]。该方案中心级综合监控系统部署实时数据库和历史数据库, 中心不担负每个车站级实时数据处理, 只负责必须由中心级实现的功能, 而将大量实时数据处理功能下放到车站一级。车站一级又分为集中站和分站, 每3~4个车站设置一个集中站 (与信号系统集中站的设置一致) , 其余为分站。集中站部署数据库, 负责各站的数据存储, 分站不部署数据库。
集中站与分站的关系:正常情况下, 集中站具有本站设备监控功能, 对分站设备只有监视功能和数据存储功能;分站监控本站设备, 分站授权给集中站后, 集中站也可以具有对分站设备的控制功能。中心级与集中站、分站的关系:正常情况下, 中心级直接与集中站互传信息, 集中站与分站互传信息;经过集中站授权后, 中心级综合监控系统可以与分站直接互传信息。该方案数据库部署及数据流如图4所示。
以上四个方案, 在运营管理方面, 方案一、方案二、方案四更适用于OCC集中运营管理, 亦即更容易向将来车站无人管理模式过渡, 方案三集中管理功能相对较为弱化, 不易将来向车站无人管理模式过渡;在系统安全可靠性方面, 方案一每一份数据均双重拷贝, 当某一车站的服务器宕机时, 不会存在数据丢失, 且其故障范围只影响本站。方案四每个数据亦双重拷贝, 但当集中站宕机时, 其故障波及范围包括本站及其分站。方案二数据仅储存于控制中心服务器内, 方案三数据仅储存于车站服务器内, 无异地备份;在投资方面, 方案一中心级软件投入较高, 车站级软件投资费用较低, 整体投资适中。由于硬件数量较多, 总体投资较高。但若考虑服务器虚拟化技术的应用, 该方案投资较低。方案二应用集中, 软件平台要求较高, 需部署大型数据库管理系统等, 软件费用较高。但在硬件上大大节约了投资, 总体投资较低。方案三由分布式数据处理软件平台及小型数据库管理软件构成。费用较低。硬件投资较方案一增加, 总体投资适中。方案四软件费用与方案一相近, 但硬件数量少于方案一, 总体投资适中;在可扩展性方面, 方案一、方案三、方案四均采用分布式模块化体系结构, 其差别主要在方案一、四中心级结构庞大, 扩展代价相对于方案三要高, 由于方案二中心集中部署, 方案三车站级采用集中站/分站结构, 其扩展灵活性比方案一、二要低。
2 服务器配置方案
服务器应根据数据库的部署方案设置, 根据冗余方式的不同, 存在不同方案, 以下以中心集中与站点分布的数据库部署方案为例, 对服务器配置方案进行分析 (以下分析同样适用于其它数据库部署方案) 。该数据库部署方案下服务器配置存在以下三个方案。方案一所有服务器冗余配置方案, 方案二为中心级服务器冗余配置, 车站级服务器邻站互备方案, 方案三采用服务器虚拟化技术集群配置服务器方案。
(1) 方案一, 所有服务器均为冗余配置, 采用双机热备方式工作。正常情况下为两台服务器同时运行, 一台服务器被指定为进行关键性操作的主服务器, 另一台服务器作为备用服务器 (配置一样) , 两机用心跳线相连, 当主机出现问题, 备机接管业务[3]。服务器工作示意图如下。
正常情况时, 如图5所示。
站内服务器发生单点故障时, 如图6所示。
这种配置是国内外的城市轨道交通工程中综合监控系统的典型配置。该方案的服务器配置档次一般即可。
(2) 方案二, 中心级服务器冗余配置, 车站级服务器邻站互备方案。
中心级配置与方案一相同, 车站级每个车站配置一套服务器, 本站服务器同时作为邻站的备用服务器, 处理本站数据业务的同时备份邻站数据。逻辑上的主备冗余的服务器采用双机互备方式工作[3]。正常情况下, 各站点服务器上分别运行不同的处理事件, 应用不同, 当某一站点主机出问题时, 其上所有应用转到邻站服务器上, 该邻站服务器将同时负担两个站点的业务处理。
正常情况下, 相当于将方案一的冗余服务器在地理位置上分散至相邻两站部署, 如图7。
当某一站点的服务器故障时, 需要邻站服务器接管故障服务器全部的应用。此时故障服务器站点工作站显示的信息需要从邻站服务器中获得, 如图8。
这种配置使站间联系较为紧密, 故障情况下服务器负载会倍增, 在国内外的城市轨道交通工程中综合监控系统的较少使用。服务器配置将高于方案一的档次。
(3) 方案三, 采用服务器虚拟化技术集群配置服务器方案。
1) 虚拟化技术
虚拟化在计算机方面通常指计算元件在虚拟架构上而不是真实架构上运行。虚拟化技术的一个典型应用就是服务器虚拟化技术, 在服务器虚拟化技术中, 同一台物理服务器上可以同时运行多个操作系统, 可以通过虚拟化技术的应用, 模拟出多台逻辑上的服务器设备, 且每一个操作系统为可以独立运行的应用系统。服务器虚拟化技术可以实现服务器物理资源到逻辑资源的转变, 让一台服务器变成几台甚至上百台相互隔离的虚拟服务器, 或让几台服务器变成一台服务器来用, 使用户不再受限于物理上的界限, 而是让CPU、内存、磁盘、I/O等硬件变成可以动态管理的资源池, 来灵活地进行资源的分配和调整[4]。
2) 采用服务器虚拟化技术集群配置服务器方案
综合监控系统仅在控制中心设置服务器集群, 通过采用虚拟化技术, 将多台服务器虚拟化为一个服务器资源池, 该资源池再向系统内的各类应用提供逻辑上独立的虚拟服务器。如图9所示。
该方案优势如下。
(1) 降低成本。通过服务器虚拟化技术, 控制和减少物理服务器的数量, 明显提高每个物理服务器及其CPU的资源利用率, 从而降低硬件成本;降低运营和维护成本, 包括控制中心和车站物理空间、耗电量、冷气空调及人力成本等。
(2) 提高运营效率。为IT基础设施中所有资源的管理访问提供单一且安全的接口, 允许管理员对所有资源进行诊断, 对所有资源进行配置和修改管理。
(3) 虚拟化技术和存储网络的有效结合, 提高了应用可用性、灵活性及安全性。相对于双机环境下每台服务器应用只能是另外一台做备份服务器, 在集群环境下, 理论上的其他服务器, 只要满足条件, 都可以是备援服务器, 实现了群集化资源的高可用性。此外, 一旦在服务器上安装并运行了群集服务, 该服务器即可加入群集, 即可以随意增加和删改集群系统的节点, 对于系统的扩展十分方便。
方案比选。综合以上三个方案, 从网络需求角度分析, 方案一站内实现系统数据处理及备份功能, 不依赖网络, 传输网络负荷较低。方案二站内实现数据处理功能, 但需要站间数据备份, 网络负荷一般。方案三对网络依赖最大, 网络负荷最高。从运营维护角度分析, 方案一和方案二差别不大, 方案三采用虚拟化技术, 服务器数量最少且仅在中心设置, 维护工作量最小。从投资成本角度分析, 方案一投资略高于方案二, 方案三最低, 若综合考虑服务器对物理空间的占用、耗电量、冷气空调及维护成本, 方案三远远低于方案一和方案二。从工程实施角度分析, 方案一最为成熟, 其对软件要求低, 实施难度小。方案二站内单服务器方便, 切换调试较难, 其对软件要求较高, 实施难度大。方案三国内外综合监控系统项目均无实施案例, 但在视频点播系统、网络搜索引擎等领域已有应用, 实施难度大。
3 小结
综合监控系统数据库部署及服务器配置方案, 应依据线路特点、技术发展水平、运营管理技术水平及需求进行选择。本文对数据库部署及服务器配置方案进行了全面的总结和归纳, 为综合监控系统的工程设计提供设计思路和方法。同时提出了基于服务器虚拟化技术的服务器配置方案, 为云计算在城市轨道交通综合监控系统中的应用提出了新的思路。
摘要：城市轨道交通项目中综合监控系统的建设, 依据线路特点、技术发展水平、运营管理技术水平及需求, 在数据库部署及服务器配置方面有不同的方案实践, 各方案均有其不同的侧重点及优缺点, 对各方案进行归纳和总结, 为综合监控系统的工程设计提供设计思路和方法。同时提出了基于服务器虚拟化技术的服务器配置方案, 为云计算在城市轨道交通综合监控系统中的应用提出了新的思路。
关键词：综合监控系统,数据库部署,服务器配置
参考文献
[1]管建华, 王凯杰, 秦小光, 等.城市轨道交通主控系统研究报告[R].天津:铁道第三勘察设计院集团有限公司, 2009.
[2]魏晓东.城市轨道交通自动化系统与技术[M].北京:电子工业出版社, 2011.
[3]GB 50636-2010.城市轨道交通综合监控系统工程设计规范[S].
交通数据库系统 篇9
随着计算机以及互联网技术的突飞猛进, “大数据时代”悄然来临。它的到来, 影响着人类社会发展的进程, 标志着继农业革命、工业革命、信息革命3次浪潮之后的数据革命的开始, 它无时无刻不在影响着人们的日常生活。大数据给人们生活带来的改变是方方面面的, 是全方位、多领域的, 当然也包括交通。大数据在改变着人们的出行方式, 使人们的出行更加便捷, 更加高效, 更有乐趣。
大数据时代的到来, 为智慧交通的发展提供了有力的支持, 同时也带来了巨大的变革。当人们乘坐地铁或公交车刷卡时, 刷卡机就记录了人们的出行次数以及上车地点, 通过对汇总过来的数据进行分析, 可以在一定程度上掌握人们的出行规律, 从而对未来的出行进行预测。现在的很多交通信号灯是动态调整配时, 它的实现方式是在交叉口附近埋置大量的传感器, 采集流量的数据, 通过对各个传感器的数据的汇总和分析, 计算出本交叉口车流量的比例, 再根据车流量、车道数的数据计算出合理的配时, 最终实现通行能力最大化。高速公路上通过高清摄像头的全程无缝隙实时监控, 交通部门可以实时掌握高速公路的运行状况, 对于车辆超速、遮挡牌照以及在非紧急情况下侵走应急车道等违法行为, 高速交警可根据视频图片证据给予处罚。这些均有利于维持良好的交通秩序。
物联网、云计算、大数据、移动互联等科学技术和相关的创新活动共同促进着智慧交通的建设, 智慧交通在交通运行管理优化、面向车辆和出行者的智慧化服务等各方面, 为公众提供更加敏捷、高效、绿色、安全的出行环境, 创造了更美好的生活。智慧交通必定会对未来城市交通的发展模式、产业发展以及融资政策产生深远影响。
2 物联网在智慧交通中的应用
为了改善我国当今社会日趋严重的交通状况, 人们应该努力提高交通运输设备及设施的信息化和智能化水平。由于物联网在网络工程、通信工程、计算机科学和人工智能等方面具有更大的技术优势, 因此基于物联网的智慧交通为现代交通运输行业提供了发展的新方向。
物联网的实质是利用射频自动识别 (RFID) 技术, 通过计算机互联网实现物品的自动识别和信息的互联与共享。在物联网中, 物品主要通过射频识别装置、红外感应器、全球定位系统、激光扫描器等信息传感设备, 把物品与互联网相连接, 进行信息交换和共享, 从而实现智能化识别、定位、跟踪、监控和管理。但是, 物联网的核心和基础仍然是互联网, 是在互联网基础上的延伸和扩展。将物联网、云计算为代表的智能传感技术、数据通讯传输技术、电子传感技术、卫星导航与定位技术等进行有效的集成, 运用于整个交通运输管理体系, 是智慧交通的一个重要标志。在这个网络中, 人、车、路密切配合达到和谐统一, 在很大程度上提高了交通运输效率, 保障了交通安全, 使整个交通体系智能化。
交通系统是一个复杂的综合体, 如果只从道路或者车辆的角度来考虑, 无法从根本上解决问题。那么在信息技术的支持下, 可以采用系统的方式来解决交通系统问题。由此可见, 物联网技术对于解决交通系统问题有很大的帮助。
物联网在智能交通系统中的应用主要表现在3个方面: (1) V2V汽车防碰撞预警系统。这一预警系统名为“V2V”, 中文意思是“车对车”, 由美国通用汽车公司研发。该预警系统利用卫星导航系统精确定位车辆所处方位, 在两车距离处于危险范围的时候发出警报, 并通过无线网络将所获取的信息传送到距离300米以内的车辆上, 提醒双方驾驶员注意并立即采取相应的措施。此外, 系统还可以自动刹车, 但车辆仍由驾驶员完全掌控。据通用公司的马歇尔介绍, 预警系统能够最大限度减少驾驶员因处于车辆盲区而看不到其他车辆带来的危险。同时, 系统也能够防止因能见度低、道路曲折或注意力不集中导致的追尾事故。 (2) Telematics通信服务系统。“车载信息服务”是指在车上安装的资讯互动平台, 通过通信网络提供的多种多样的信息来实现。该系统通过呼叫中心和数据中心为车主提供“点对点”的服务, 可以实现包括远程车辆诊断、失窃车辆定位、撞车自动报警、气囊打开报警、道路救援等在内的车载智能通信服务, 通过人机对话设置的车载导航, 结合服务平台收到的实时路况信息, 从而避开道路拥堵和车辆高峰, 给驾驶员提供道路指引, 给用户行车提供最大的方便。此外, 随着越来越多的传感器在车身上的应用, 呼叫中心可通过收集实时路况信息为车主提供合理的应急方案和维修方案。 (3) 互动式公交车站Eye Shop系统。美国麻省理工学院“感知城市实验室”正在研究一种互动式公交车站, 该车站可以使人们在等车时有更多的事情可做, 从而减少等待公交的无聊枯燥感。该设计的思想是:人与数字环境的互动应该达到无时无刻, 在开放的空间中提供开放式服务, 让人们在等车的同时还可以进行信息查询、规划旅游线路、阅读以及娱乐等。该系统将公交车站变为人与物可以互动的车站, 同时提供互动式地图、分类广告、路线规划、公告栏等, 实实在在地让公交站成为人们休闲娱乐的场所。
3 数据挖掘在智慧交通领域的应用
智慧交通是改善城市交通的关键, 但是, 及时、准确地获取交通数据并构建交通数据处理模型是建设智慧交通的前提, 这一难题可通过数据挖掘技术得以解决。交通数据复杂庞大, 交通信息来源广泛, 种类和形式均多种多样, 信息量巨大, 利用海量的数据找到有用的信息则变成交通工作者的首要任务。根据交通数据的特点, 传统的数据分析方法大多是采用统计和多维数据分析方法, 这些方法均无法解决复杂庞大的交通数据。然而随着数据挖掘技术的发展, 在交通数据分析中更好地结合传统的分析技术和新兴的数据挖掘技术对交通难题进行分析和预测使人们看到了新的希望。
数据挖掘是从大型数据库的数据中提取出隐含的、事先未知的、但潜在有用的信息和知识的过程。确切地说, 数据挖掘的过程是一个决策支持过程, 主要基于数据库、人工智能、数理统计、机器学习等技术, 自动化地分析生产线中原有的数据, 进行归纳推理, 从而挖掘出潜在的模式, 预测用户的行为, 帮助驾驶员调整行车路线, 规避车流量高峰期和风险, 作出正确的决策。随着互联网时代的到来, 城市中各种各样的数据呈现出爆炸式增长的态势, 这使人们进入了数据时代, 但同时也面临着不能及时获取实时信息等问题, 因此人们迫切需要一种能从海量数据中发掘有用信息的工具, 数据挖掘正是顺应这种需求诞生的。
数据挖掘通常有几个任务:关联分析、聚类分析、分类分析、时序模式和偏差分析。常用的数据挖掘方法有:决策树方法、遗传算法、人工神经网络、最近临技术和规则归纳, 此外, 还有可视化方法以及公式发现方法。为了解决交通拥堵和交通事故问题, 可以利用数据挖掘中的分类技术对历史交通问题进行分析, 提取发生交通拥堵时的规则, 然后用道路或者路口的交通数据来匹配这些规则, 将可以很好地预测交通拥堵问题的发生;对于交通事故, 关键是从已发生的交通事故数据中发现问题, 分析事故的原因, 可以方便相关部门及时采取相应的有效措施, 数据挖掘中的关联分析可以推导出一些有用的规则表达式, 展示出事故发生时各种客观因素对事故发生的影响程度。
除此之外, 数据挖掘还应用在许多其他领域。针对每一种特定领域, 开发专用的数据挖掘工具, 其中包括生物医学、DNA数据分析、金融数据分析、零售业和电信等。数据挖掘存在许多序列模式分析和相似检索技术, 成为DNA分析中的强有力工具, 在DNA序列间相似搜索和比较、关联分析、同时出现的基因序列的识别、路径分析和遗传数据分析等方面起着不小的贡献;在金融数据分析方面, 可以对目标市场客户进行分类与聚类, 也可以帮助洗黑钱和其他金融犯罪的侦破;零售数据挖掘可以利于促销活动的有效分析, 识别顾客的购买行为, 改进服务质量, 提高货品销量, 从而取得更好的顾客口碑;在电信领域, 可以利用数据挖掘技术对电信数据进行多维分析, 识别盗用模式和异常模式, 从而更好地利用资源和提高服务质量。
基于物联网的智慧交通大数据挖掘系统是一个服务于大型城市的、具有自适应性的智慧应用与整合能力的项目, 保证该项目成功的前提是设立一套科学、合理的方法论和管理过程模型, 同时为项目的大规模复制和推广创造基础条件。相信随着物联网技术和数据挖掘技术的不断进步, 它们终将科学、高效地服务于城市, 智慧交通以及整个智慧城市系统会越来越完善, 人们的城市生活会更加美好。
参考文献
[1]彭晓珊.关于物联网技术发展及应用前景研究[J].汕头科技, 2010 (1) :25-30.
[2]科技, 让交通更智慧[N].上海科技报, 2014-10-20.
交通数据库系统 篇10
近年来, 电子信息领域的技术发展极其迅速, 对智能交通系统发展带来了重大变革。物联网、云计算、大数据、移动互连等技术在交通领域的应用和发展, 不仅给智能交通系统注入新的技术内涵, 也对智能交通系统的模式、理念产生了巨大影响。目前, 国际智能交通领域的车路协同系统、公众出行便捷服务、车联网等热点技术领域, 都在广泛研究和应用云计算、大数据、移动互联等新技术。我们注意到, 今年10月在日本举办的第20届世界智能交通大会上, 交通大数据的研究非常活跃并已经形成了许多具有良好应用前景的创新成果。随着研究和应用的深入, 大数据技术在交通运行管理优化、面向车辆和出行者的智能化服务, 以及交通应急和安全保障等方面都将形成巨大的市场。
大数据时代智能交通发展的需求与机遇
1) 智能交通系统发展的数据分析需求:
一方面, 交通数据采集的范围、广度和深度急剧增加, 随着智能交通系统建设规模的不断扩大, 正在形成以微波、线圈、GPS、车牌等交通流检测数据, 交通监控视频数据, 以及系统数据和服务数据等为主体的海量交通数据。以北京市为例, 6万余辆出租车一天就会产生数亿条GPS数据, 车牌识别、交通监控视频等数据量更大, 交通相关的数据量级已从TB级别跃升到PB级别, 传统的交通数据分析方法已很难有效支撑这么庞大的数据体的开发与利用。
另一方面, 对动静态海量交通数据的挖掘分析成为智能化交通信息处理分析的核心内容, 交通数据的深层价值有待进一步的挖掘和开发。根据调查, 韩国3G手机上的服务中, 有50%以上的服务与交通有关, 包括实时道路交通信息、地铁和公交信息、火车和飞机班次动态信息、换乘信息、与汽车服务有关的信息等。以智能终端为服务窗口的、以云计算和大数据分析技术为支撑的智能交通信息服务正在逐步成为主流, 与我们的生活息息相关。
2) 大数据分析为智能交通发展带来的新机遇:
一是大数据技术的海量数据存储和高效计算能力, 将实现交通管理系统跨区域、跨部门的集成和组合, 将会更加有效地配置交通资源, 从而大大提高交通运行效率、安全水平和服务能力。二是交通大数据分析将为交通管理、决策、规划和运营、服务以及主动安全防范带来更加有效的支持。三是基于交通大数据的分析为公共安全和社会管理提供新的理念、模式和手段。
大数据背景下智能交通发展面临的问题与挑战
交通大数据时代的来临是智能交通发展的必然趋势, 在这个进程中我们也将面临前所未有的问题和挑战。所面临的问题主要有几个方面:一是交通数据分散在不同部门 (我国与交通相关的部门有10多个) , 而部门之间又缺乏开放互通, 造成了交通数据资源的条块化分割和信息碎片化等现象;二是由于交通检测方式多样, 信息模式复杂, 造成数据种类繁多, 且缺乏统一的标准;三是目前尚缺乏有效的市场化推进机制, 基于大数据的交通信息服务产业链、价值链尚未真正形成。
解决这些问题, 需要做好几项挑战性工作:一是如何从政策和技术上突破交通数据资源互通、共享的壁垒, 消除信息分散、内容单一等问题;二是如何确保交通数据资源的安全性, 在数据开放的同时, 加强数据的安全监管, 尊重和保护相关政府部门、交通企业以及个人的机密和隐私不受侵犯;三是如何实现交通数据资源的综合利用效率, 将交通路况检测、GPS、交通监控视频等零散信息进行有效地联系、汇聚和发掘, 使其能够真正支撑交通系统的运营管理, 提高交通运行效率和安全水平。
大数据时代智能交通的发展趋势
大数据时代背景下, 立足国情, 运用新技术手段, 结合智慧城市建设, 构建具有中国特色的新一代智能交通系统, 是我国智能交通发展的重要方向, 重点要开展以下几个方面的工作:
1) 持续提升交通感知智能化水平, 完善网络化的交通状态感知体系:感知是一切数据来源的前提。“十二五”时期, 要突破车路状态感知与交互等关键技术, 包括车辆动态组网、状态实时获取、环境智能感知、车路信息交互等一批前沿技术, 提升交通运行监测能力和水平。要建设覆盖主要道路、公交场站、高速路口、轨道交通站点、综合运输枢纽的数据传感网络, 形成全路网智能监控体系。要推动地面公交、轨道交通、民航、铁路、交管、气象、消防等部门实现信息共享, 为交通大数据分析提供海量数据基础。
2) 加强交通数据标准化建设, 进一步整合数据资源:推进智能交通系统的数据标准化建设, 特别是要建立和完善智能交通系统的接口规范和数据标准体系, 为跨部门、跨区域的智能交通信息系统的互联互通奠定基础。同时, 还要加强数据安全防范措施, 提升数据监管和保护能力, 维护数据的安全使用。综合交通相关的不同部门、不同区域、不同类型的“数据仓库”, 整合交通数据资源, 建立综合性立体的交通信息体系, 形成智能交通数据资源共享平台, 提升交通数据资源的整体性服务能力。
3) 创新交通大数据分析应用, 实现基于大数据技术的交通系统高效运营和管理:基于交通数据资源互联共享、标准统一的原则, 构建完备或准完备网络化交通信息环境, 实现跨区域、跨模式的大范围出行调控、网络化诱导的协同联动控制。以互通的交通信息平台为基础, 形成城际公路、铁路、民航等交通系统的协调运行体系, 强化交通运营管理的整体性功能, 通过多个交通部门的相互配合, 实现步调一致的协同管理, 为交通运行高效有序、居民出行安全便捷提供更有力的保障。
4) 建立基于大数据分析的新一代智能交通信息服务系统, 改善和提高公众出行的智能化服务水平:为满足公众出行多样化、个性化、动态化交通服务需求以及交通应急救援、跨行业综合交通服务需求, 要应用大数据、云计算、新一代宽带移动通信、智能终端等新技术, 大力推进个性化的移动服务发展, 并创造新型商业模式, 鼓励交通管理、载运工具制造、信息产业等多方组成联盟, 一起推进新一代的交通信息服务系统的建立, 让民众“随时随地”享受到交通信息智能服务带来的便利。要建设跨区域、多模式的综合交通电子支付系统。基于大数据技术建立全国联网电子收费结算体系网络信任平台, 建设国家高速公路联网电子收费清分结算和客户服务体系, 实现全国范围跨区域电子不停车收费服务。加快交通一卡通跨区域、跨行业的互联互通, 实现出行中的便捷支付。推动公路与城市车辆收费一体化, 实现交通需求管理的科学化, 并最终形成跨区域、多模式的综合交通电子支付体系, 为公众出行提供更加智能的服务。
5) 构建并完善智能交通技术创新体系, 加强交通信息服务产业化进程:
加强智能交通科技产业创新联盟平台的建设, 强化企业技术创新主体地位, 加强产学研之间的联系与互动, 注重协同创新, 提高企业技术集成能力。加大研发投入, 促进从研究开发到产业化的有机衔接, 加快科研成果转化和技术转移。充分利用国际科技资源, 扩大智能交通科技开放合作, 并加大对知识产权的保护力度。
建立交通数据采集、更新、共享和信息发布制度, 明确各相关方在数据质量标准以及信息交换方面的责任和义务。建立公益服务与市场化增值服务相结合的交通信息资源开发利用机制, 将交通运输各利益相关方通过价值链连接起来。交通信息按照市场引导、价值驱动的方式在各利益相关方之间流动, 并逐步形成新的市场和营利点, 加快交通信息服务的产业化进程。
