• / 198
  • 下载费用:10 金币  

智能交通集成指挥中心建议方案.pdf

关 键 词:
智能 交通 集成 指挥中心 建议 方案
资源描述:
智能交通集成指挥 中心 解决方案 苏州金螳螂怡和科技股份有限公司 Suzhou Gold Mantis Yihe Technology Co., Ltd 第 2 页 金螳螂怡和科技 目 录 第 1 章 项目概述 . 8 1.1. 项目背景 8 1.1.1. 问题分析 8 1.1.2. 需求分析 9 1.2. 建设原则 9 1.3. 建设依据和标准 12 1.4. 建设目标 14 1.5. 建设内容 16 第 2 章 总体设计 . 17 2.1. 总体业务设计 17 2.1.1. 设计思想 17 2.1.2. 设计目标 19 2.2. 总体技术路线 20 2.2.1. 技术理念 20 2.2.2. 技术路线原则 22 2.2.3. 异构系统互操作关键技术 22 2.2.4. 海量数据存储关键技术 28 2.2.5. 交通流信息采集与发布关键技术 31 2.2.6. 多尺度地理空间数据的分布式存储与管理 35 第 3 页 金螳螂怡和科技 2.3. 总体系统架构设计 37 2.3.1. 系统架构 37 2.3.2. B/S 和 C/S 混合多层结构 . 41 2.3.3. SOA 架构 . 42 第 3 章 集成指挥平台系统 . 44 3.1. 系统概述 44 3.2. 系统功能结构 45 3.3. 层次模型 45 3.4. GIS 地理信息平台 . 47 3.4.1. 系统概述 47 3.4.2. GIS 接口设计 . 49 3.4.3. 电子地图空间数据加工 50 3.4.4. 矢量数据 50 3.4.5. PGIS 专题地图制作 51 3.4.6. 制作网格地图 51 3.4.7. 数据整合建库 51 3.4.8. 数据字典 51 3.4.9. 地理信息编码 52 3.4.10. 地图比例 54 3.4.11. 数据图层分类 55 第 4 页 金螳螂怡和科技 3.4.12. 系统关联 56 3.5. 平台系统信息关联与交互 57 3.5.1. 原理及工作方式 57 3.5.2. 技术特征 58 3.5.3. 系统架构 59 3.5.4. 技术路线 61 3.5.5. 集成指挥平台与已建基础业务系统的交互 65 3.5.6. 集成指挥平台与市公安局指挥中心的信息交 互 84 3.5.7. 集成指挥平台与辖区大队业务系统的信息交互 85 3.6. 基础应用系统集成功能 86 3.6.1. 集成交通信号控制系统模块 87 3.6.2. 集成监控设备控制系统模块 89 3.6.3. 集成警用车辆定位系统模块 100 3.6.4. 集成交通诱导信息发布系统模块 105 3.6.5. 集成交通流量检测系统模块 . 110 3.6.6. 集成闯红灯自动记录系统模块 . 113 3.6.7. 集成移动警务系统模块 . 117 3.6.8. 集成警用地理信息系统( PGIS)模块 119 3.7. 指挥调度功能 123 3.7.1. 系统概述 123 第 5 页 金螳螂怡和科技 3.7.2. 交通警情管理功能 123 3.7.3. 交通预案管理功能 125 3.7.4. 突发事件指挥调度功能 131 3.8. 特勤保障功能 136 3.8.1. 系统概述 136 3.8.2. 业务流程 137 3.8.3. 快速特勤 137 3.8.4. 制定特勤方案 138 3.8.5. 审批特勤方案 140 3.8.6. 执行特勤方案 140 3.8.7. 评估特勤方案 143 3.9. 勤务管理功能 143 3.9.1. 勤务管理子功能 143 3.9.2. 接报警信息和事故黑点 146 3.9.3. 警员和车辆的管理 148 3.10. 交通态势监控功能 156 3.10.1. 数据采集功能 157 3.10.2. 信息发布 160 3.11. 交通设施管理功能 165 3.11.1. 管理内容 165 第 6 页 金螳螂怡和科技 3.11.2. 设备维护 165 3.11.3. 设备状态监控 167 3.11.4. 报修模块 167 3.11.5. 报表管理 169 3.12. 综合分析研判功能 171 3.12.1. 交通流量统计 171 3.12.2. 交通违法记录系统信息查询 174 3.12.3. 交通违法重点地段的排查 174 3.12.4. 交通违法情况趋势分析 175 3.12.5. 交通事故数据采集标注 176 3.12.6. 交通事故分布与统计分析 176 3.12.7. 交通事故黑点排查 180 3.12.8. 交通违法事故情况趋势分析 182 3.12.9. 交通事故成因分析 183 3.13. 稽查布控分析功能 184 3.13.1. 概述 184 3.13.2. 系统功能 184 3.14. 交通违法预处理功能 185 3.14.1. 概述 185 3.14.2. 系统功能 186 第 7 页 金螳螂怡和科技 3.15. 信息发布功能 190 3.15.1. 概述 190 3.15.2. 系统功能 190 3.16. 时间校准功能 194 3.17. 运维管理功能 194 3.17.1. 设备运行管理 195 3.17.2. 网络运行管理 196 3.17.3. 日志管理 196 3.17.4. 平台安全管理 196 3.17.5. 数据备份管理 196 3.17.6. 权限管理 197 3.18. 交通基础数据采集 197 3.18.1. 数据采集范围 197 3.18.2. 数据录入 197 3.18.3. 数据存储 197 3.19. 平台支撑软件 198 3.19.1. 集成指挥平台软件 198 3.19.2. 中间件 198 3.19.3. 数据库软件 198 第 8 页 金螳螂怡和科技 第 1章 项目概述 1.1. 项目背景 1.1.1. 问题分析 虽然 基础应用系统已经达到了较高的技术和应用水平,但也存在着一些问题 和不足:各应用系统只针对本系统的数据处理,局限于简单的统计,统计信息都 有其局限性,出现“信息孤岛”现象,无法实现数据融合、信息共享 ,为交通运 行评估和辅助决策提供依据,不能进行相关系统的协同联动,使之在日常工作中, 工作效率仍没有显著提高。 由于缺少科学管理手段, 各 交通管理部门,越来越 难 以适应当前形势的要求。 主要表现在: 图 1.1-1 问题分析 1. 信息孤岛问题 为了提高城市交通管理科技水平, 国内 各地相继建立了交通信号控制系统、 电视监控系统、电子警察系统、信息诱导发布系统、 122 接处警系统、 GPS 车辆 定位系统、车辆、驾驶员、违法、事故等交通管理业务信息系统等,大大缓解了 城市有限路网资源和迅猛增加的交通需求之间的矛盾。 这些系统都是在不同时期由不同厂家建设完成,每个系统建设时期没有考虑 其他技术系统的互联 互通,使得已建成的各个技术系统目前基本处于独立运行状 第 9 页 金螳螂怡和科技 态,彼此之间缺乏信息交换,就城市交通管理的全局而言形成了技术系统的信息 孤岛,无法满足资源共享、协同指挥的要求,这些技术系统的综合应用受到极大 的限制。 2. 缺少信息融合分析及挖掘 目前 公安交巡警支队 对于交通基础数据的利用还只是停留在对 机动车、驾驶 人、交通违法、交通事故 等 基础业务信息 的简单采集上,甚至有些地方对基础业 务信息的采集手段都存在着欠缺。对于业务 数据的综合分析和深层次挖掘, 在目 前的交通管理中仍然还是十分不完善的, 各种采集数据没有统一的数据融合机制 , 对 信息的利用非常少 , 这导致了交通管理部门难以 实时掌控路面的交通状况,更 难于掌握 辖区内 交通管理未来的发展态势。 3. 信息服务、协同指挥功能补助 目前, 公安交巡警支队 由于缺乏应急指挥调度的科技手段, 没有完整的信息 发布流程和系统,并且子系统之间还无法形成相互联动的机制, 指挥人员遇事只 能凭经验、靠电话指挥调度。对重特大交通突发事件、特别是跨越地区的突发事 件难以做出准确判断和快速处理。 1.1.2. 需求分析 通过现状分析,可以总结出以下的建设需求: 急需建设智能化的智能 交通 集成 指挥平台。通过集成平台的建设,使得各个 子系统间的数据 共享与交换更加便捷,并可实现指挥调度、预案及辅助决策以及 服务的功能。 1.2. 建设 原则 智能交通集成指挥平台设计将 本着“实用、可靠、开放、兼容、先进、成熟、 可扩展与可定制”的原则 进行 ,充分利用现有资源,结合当前技术发展状况及趋 势,考虑项目建设和日后运行的成本以及公安技防工作的特殊性,在系统的研发 设 计、生产制造、测试运行的过程中 严格遵循以下原则: 第 10 页 金螳螂怡和科技 1、 实用性 (1) 充分利用成熟的先进技术,采用性能 /价格比较高的产品; (2) 体系结构、软硬件选型,既保证实用成熟,又能够适应未来的业务发 展和技术的更新要求。 (3) 软件符合管理需要,界 面友好、易维护,整个系统易用、实用。 2、 可靠性 (1) 本项目系统设备 选用主流产品,保证系统的高质量和高稳定性,能够 适应野外恶劣环境工作,同时采取有效的防雷、接地、稳压等措施; (2) 系统最大限度集成世界上稳定且先进的技术及组件,采用成熟技术以 降低系统的不稳定因素; (3) 对系统如硬件、操作系统、网络、数据库设计尽可能详尽的故障处理 方案,以保证系统的快速恢复性; 3、 开放性 系统的技术方案和设备具有良好的互联、互操作能力及升级能力,遵循最新 的国际标准、国家标准和行业标准,具有良好的开放性。 4、 先进性 (1) 本项目 系统的网络平台、硬件平台、系 统软件平台技术代表了当今计 算机技术发 展的方向, 符合当今计算机科学的发展潮流。 (2) 系统 为 各平台提供二次开发接口,保证各项技术可以不断的更新和升 级以维持系统的先进性。 (3) 本方案采用目前正流行的 B/S 三层架构设计 ,以及最新的 Spring , Hibernate, Web service 技术 ,结合 Flash 平台 的 富 Internet 应 用程序。 5、 可扩展性 第 11 页 金螳螂怡和科技 在系统软硬件上的设计和选型上, 充分考虑其可扩展性, 接口开放性, 系统 结构易于扩充,以适应今后可能出现的更大任务负载。硬件平台具有可升级性, 当需要时可以增加新的计算机设备 同原有计算机设备一起工作以提高系统的处理 能力,保证原有资源的充分利用。 本方案 基于 Web service 技术 , 即可以支持普通的浏览器方式访问,也可以 提供基于底层 Socket 方式 API 的访问 ,并 且提供 VC、 Java 多种访问接口。 建立集成指挥平台,牵涉的面广,需要综合考虑的因素较多,因此我们在设 计中心软件平台时将全面考虑各方面的需求,充分完善使整个系统具有很好的扩 展性和包容性。 6、 安全性 有抵抗恶性攻击、抵抗任何侵入系统的企图和抵抗企图从系统中获取敏感数 据和信息的能力,具有一定的防暴力破坏和防窃取信息的能力。保 证数据和照片 的安全性、保密性、完整性、一致性和相容性。 本方案中采用高精度加密方式实现统一身份认证,最大限度的保障用户信息 的保密性、系统数据的安全性、系统功能的可靠性。 7、 跨平台性 本系统可以在 Windows/Linux/Unix 等多种平台上运行。具有很好的平台无 关性 和安全性 。 8、 经济性 本 方案 设计从 Web 服务器 到报表开发全部基于 Java 开源技术,不涉及任何 商业技术,拥有独立的技术产权,大大降低开发成本。 9、 稳定性 在大型集成系统中采用 Java 技术是首选,基于 JAVA 开发的 WEB 服务和通信 服务在稳定性,特别是协议 扩展的便利性和稳定性上经受了实践的考验。 第 12 页 金螳螂怡和科技 10、 易维护性 (1) 本项目系统平台 符合业内通用规范,易于维护。 (2) 系统各类应用软件界面友好,安装、使用、维护应简单便捷。 (3) 业务流程清晰,符合常规业务处理习惯。 (4) 系统数据维护方便,备份及数据恢复快速简单。 (5) 系统软件配置简单方便, 避免复杂的系统配置文件。 1.3. 建设 依据 和标准 1. 《交通管理信息系统建设框架》; 2. 《中国智能运输系统体系框架》; 3. 《计算机信息系统安全保护等级划分准则》( GB17859); 4. 《公安交通指挥系统建设技术规范》( GAT445-2010); 5. 《公安交通指挥系统设计规范》 ( GAT515-2011-2); 6. 《公安交通指挥系统工程建设程序与要求》( GA/T651); 7. 《道路交通信息采集信息分类与编码》( GB/T20133); 8. 《道路交通信息采集事件信息集》( GB/T20134); 9. 《智能交通集成指挥平台通用技术条件》 (公安部 GA/T496-2009); 10. 《道路交通信息采集信息分类与编码》( GB/T20133); 11. 《道路交通信息采集事件信息集》( GB/T20134); 第 13 页 金螳螂怡和科技 12. 《公安交通指挥系统建设技术规范》( GA/T445); 13. 《城市警用地理信息系统分类与代码》( GA/T491); 14. 《 城市警用地理信息系统图形符号》( GA/T492); 15. 《城市警用地理信息系统建设规范》( GA/T493); 16. 《闯红灯自动记录系统通用技术条件》( GA/T496); 17. 《公路车辆智能监测记录系统通用技术条件》( GA/T497); 18. 《城市交通交通流量控制系统术语》( GA/T509); 19. 《交通电视监控系统验收规范》 (GA/T514); 20. 《公安交通指挥系统工程设计制图规范》( GA/T515); 21. 《城市道路交通交通流量控制方式适用规范》( GA/T527); 22. 《城市警用地理信息属性数据结构》( GA/T529); 23. 《城市警用 地理信息数据组织及数据库命名规则》( GA/T530); 24. 《城市警用地理信息专题图与地图版式》( GA/T531); 25. 《城市警用地理信息数据分层及命名规则》( GA/T532); 26. 《城市警用地理信息数据采集与更新规范》( GA/T627); 27. 《城市警用地理信息空间数据质量》( GA/T628); 28. 《警用电子地图坐标系与比例尺》( GA/T629); 第 14 页 金螳螂怡和科技 29. 《安全防范工程技术规范》 (中华人民共和国国家标准 GB50348-2004); 30. 《安全防范系统雷电浪涌防护技术要求》 (GA/T 670-2006); 31. 《信息安全管理实用规则 》( ISO/IEC17799) ; 32. 《机动车登记信息代码》( GA24.1-24.21) ; 33. 《机动车号牌图像自动识别技术规范》( GAT833) ; 除上述规范以外,还遵循国家现行的相关标准和规范要求以及国家和地方相 关规划。 1.4. 建设目标 参照 公安智能交通管理系统建设规划( 2013-2017 年)、 统筹建设的要求,本 着关注民生,提高生活品质的建设宗旨。 主要围绕实现交通流采集、交通集成指 挥调度管理、信息服务三大功能展开。以“信息服务为核心,宏观管控为手段, 增强协调指挥能力,营造全市区交通安全、畅通、有序的管理格局”的 总体目标 的重要手段,是实现公众出行更便捷、协作互联更充分的主要方法。实现信息化 公安交警管理成效上台阶 , 满足成功举办 2014 年江苏省第十八届运动会对城市管 理、公共服务和政府能力提升的需求。 系统建设目标如下: 1. 缓堵保畅 的建设目标 通过建设先进的交通指挥中心 集成平台 ,在采集的交通流信息基础上制定实 时有效的交通管理措施和控制方案,不仅使交通管理者能够更全面了解路网上的 交通状况,同时根据路网上交通流的分布,通过给交通参与者提供交通信息,科 学合理地诱导交通参与者的出行路线,使交通流能够尽量合理地分配在路网上, 避免拥堵的 发生。 通过实时、动态地采集与交通管理相关的信息,如交通流信息、民警分布信 息、车辆信息等,调用预案 /方案,制定出适宜方案,通过指集成平台进行指挥调 第 15 页 金螳螂怡和科技 度,并监督指挥方案的落实情况。 通过 GIS 地理信息系统直观观察交通运行状况,通过集中对数据分析、对比, 形成日常警力部署依据,重点解决拥堵较为严重的路段路口,充分利用有限的警 力,达到最优的路况疏导效果。另可根据交通流量情况对 交叉口 信号控制 优化改 造 提高道路节点通行能力 。 2. 治安防控 的建设目标 利用计算机信息处理技术,实现多系统的集成联动应用、大数据的分析、研 判功能, 通过将治安防控系统中的视频监控、电子警察、治安卡口等视频信息子 系统及车辆定位、交通数据采集、人口管理、案事件管理等数据信息统一集成在 本期建设的指挥集成平台上,从而实现对社会治安态势的全方位控制和预防,达 到以各子系统的协调联动。集成平台的建设,有效地整合了公安机关各专用系统 资源,建立一定规模的智能联动防控体系,更有效、更广泛地为全社会提供治安 防控服务。 3. 警力管控 的建设目标 警务通系统、 GPS 车辆定位系统 是 路况巡视、勤务考核、快速事件处置体系 中的 重要 组成部分,系统的建设目标是:实时监控管理的警车、巡逻车和事故处 理车的运行路线及位置,方便指挥调度人员随时掌握我局机动警力的布控情况及 运行路线,根据实际情况进行调度部署 。 本期集成平台对于警力管控方面主要体现在以下三点: 1. 快速的事件处置警力调度 基于 GIS 地理信息系统的 GPS 定位系统集成,可实现对 警车实时位置查看 、 轨迹回放 、 信息统计 、 信息(语音、文字)交互 ,对警员位置的实时掌握,指挥 中心接到人工报警、警员上报或事件检测系统自动检测到的道路拥堵、事故等紧 急事件时,交通指挥员可直观的判断当前路面值勤警员的位置,并可在 GIS 地图 上进行圈定,快速的调度就近警员赶往事发点, 并形成接处警报告,方便后续对 事件的跟踪、评价。 第 16 页 金螳螂怡和科技 2. 勤务值班查岗 通过 GPS 定位系统,指挥中心领导可实时查看当前值勤警员所处的位置,是 否按预定时间和地点进行巡逻。 3.特勤保卫任务时的警力部署 在执行特勤保卫任务时,集成平台通过 GPS 定位系统的集成接入,可实时观 察特勤路线上所有警员的位置,特勤车队前导车的实时位置。结果视频监控系统、 交通诱导、信号控制系统完成特勤任务保卫的顺利执行,因此在执行特勤任务时, GPS 定位系统的意义是十分重要且必要的系统集成应用。 1.5. 建设内容 本项目建设内容 包含集成指挥平台软件开发和 硬件 建设 等。集成指挥平台部 署于支队指挥中心。 集成指挥平台软件 开发包括 : PGIS 平台二次开发、集成系统、指挥调度系 统、特勤任务系统、交通态势监控系统、交通设施管理系统、综合分析研判系统、 稽查分析系统、交通事故分析模块、交通信息发布系统、运维管理系统等。 硬件 建设包括:集成指挥平台服务器、授时系统、千兆核心交换机、存储、 防火墙、网闸、工作站、便携工作站、 KVM 套件、机柜等设备。 本项目包含项目施工深化设计、施工组织设计、软件开发、设备供货(服务 器、交换机、存储、防火墙、网闸、工作站等)、运输、保管、安装、调试 、试运 行、预验收、竣工验收、技术培训、提供技术资料和备件等工作,直至三年免费 维保期满为止,并保证各部分 项目 的运行正常。 第 17 页 金螳螂怡和科技 第 2章 总体 设计 2.1. 总体业务设计 智能 交通 集成指挥平台通过技术手段 实现系统间的关联与交互、信息共享、 集成联动,实现 了 各子系统所无法单独完成的功能, 为交通管理业务提供科技支 撑,在交通管理不同业务中,联合多个不同的系统高效、智能的对交通业务进行 管理及处理 。 交通集成指挥平台能够在交通管理业务中 实现“ 缓堵保畅、治安防 控、警力管控”三大建设目标,达到“事前 预警、事中控制、事后研判”的三大 建设效果 。智能交通集 成指挥平台为交通提供了智能管理、智慧出行的重要支撑。 2.1.1. 设计思想 图 2.1-1 设计思想 1. 采交通数据之 “ 水 ” 第 18 页 金螳螂怡和科技 通过各个交通子系统针对各自的交通管理领域采集交通数据,并将存储到各 自的数据库中,通过智能交通集成指挥系统将所有子系统的数据汇集到统一的数 据库中,实现多种数据联合分析,为智能交通管理数据底层提供充足的“水源”。 2. 行交通管理之 “ 云 ” 通过建设智能交通集成指挥系统覆盖全部交通管理业务,实现对交警不同业 务的智能化、高效 管理管理,并通过对采集数据以及历史数据进行深入挖掘、计 算及分析,可实现对道路交通进行预测、优化、处理、分析等功能,例如:交通 路况判态、计算信号配时优化方案、交通事件报警及处理等,实现多系统多数据 联合分析管理,实现智能交通系统业务的云覆盖。 3. 布信息服务之 “ 雨 ” 通过建设智能交通集成指挥系统分析道路交通情况后,可通过不同方式优 化、处理、发布交通事件及信息,例如:通过下发信号配时优化方案可对道路通 行能力进行优化,也可通过交通诱导屏、网站、短信、广播电台等渠道发布交通 路况信息及交通事件信息。能够提升交通通行能力,并 使交通参与者及时掌握交 通情况。使交通信息像“雨水”一样灌溉整个城市交通。 4. 润公众出行之 “ 土 ” 通过建设智能交通集成指挥系统的建设,实现对交通管理能力、交警工作效 率、公众交通规范出行等的提高,并大幅度提升交通通行能力及交通服务能力, 为公众提供一片良好交通环境的“土地”。 第 19 页 金螳螂怡和科技 2.1.2. 设计目标 图 2.1-2 设计目标 1. 事前预警 通过智能交通集成指挥平台建设对历史事件进行分析,根据不同的历史事件 处理记录编辑预案信息,为日后事件处理手段 提供依据及方案。 2. 事中控制 在事件发生或执行任务时(如:指挥调度、特勤任务),可根据不同的事件 对外场子系统进行联动控制,为事件处理或执行任务提供科技手段,提高工作效 率。如:指挥调度时,通过查看道路视频了解交通状况及监视事件发展情况,通 过信号控制疏导交通,通过诱导信息发布提醒车辆注意,通过与 GPS 车辆或警员 移动终端联系调度警员处理事件等。 3. 事后研判 在事件处理结束后,对历史事件记录进行分析,了解事件发生规律及事件多 发点等,根据分析结果可对交通管理侧重点进行调整,对事故多发地区重点关注, 也可为不同类型事件制定处 理预案提供依据。 第 20 页 金螳螂怡和科技 2.2. 总体技术路线 智能交通集成平台 是指通过各种 交通 信息传感 设备 ,实时采集任何需要 监 控 、连接、互动的物体或过程等各种需要的信息, 结合形成的一个巨大网络。其 目的是实现 车 与物、物与人,所有的与网络的连接,方便识别、管理和控制 。 平 台的 构成 分为 五 个层级 ,分别是 支撑层、感知层、传输层、平台层,以及应用层。 感知层 利用动态跟踪捕获技术与自动感知技术,实现基于高清视频的车辆通 行信息全方位捕获,形成交通管控高清视觉感知体系; 传输层 依托计算机网络和分布式队列技术,实现 GB级数据秒级传输与分发, 形成能力可线性扩展的治安交通管控高并发数据交换平台; 平台层 基于 ORACLE 数据库处理机制,实现对车辆通行数据的高效存取访 问、快速分析及深度挖掘,研发综合信息服务中间件,形成能力可线性扩展的分 布式存储与大数据批处理平台; 处理层 基于 S4/STORM 的流式数据处理 技术,实现对高并发实时车辆通行 数据的实时处理,从而实现实时布控报警、实时黑名单中心比对、实时增量型套 牌假牌检测,形成能力可线性扩展的分布式卡口流数据处理平台。 在此基础上科学建立层次化、模块化的系统架构,以可支持数学模型的快速 扩展与定制的分布式数据存储与处理平台为基础、;以面向治安交通核心业务服务 程序为中间件;以基于 B/S 应用软件的 SAAS 综合业务应用服务,形成治安交通 智能化综合管控平台。 2.2.1. 技术理念 交通 集成指挥平台 是一个构建在各业务子系统之上的大型指挥调度系统。通 过 交通 集成指挥平台 ,实现系统间的关联与交 互、信息共享、集成联动,实现各 子系统所无法单独完成的功能,为指挥调度提供综合性资源。交通管理集成平台 有其自身明显的应用特性,如:需要统一身份验证、系统间信息交互采用统一规 第 21 页 金螳螂怡和科技 范的集成协议、各系统间的数据 -功能分层支撑、平台内实现业务综合应用、实时 控制与数据分析应用并存。 交通 集成指挥平台 规划统一的身份验证机制,实现权限的统一管理,无论用 户工作关注点是什么,所用智能交通管理平台的哪个组成部分,在整体智能交通 管理平台上,他只有一个登陆用户名,系统管理员仅需要对此用户进行授权管理。 交通集成指挥平台各功能模块内聚封闭 ,对外接口抽象规范,模块间服务关 系层次化。交通集成指挥平台在面向事件的指挥调度的实现中,综合管理控制类 的应用和数据分析类应用,实现对警情周边警力资源、设备资源与预案信息的综 合应用,完成警情处置。各控制系统提供的多种控制功能和多数据源分析获得的 各类研判结果有相对的独立性,所以要采用模块功能内聚和多层构建的技术路线。 各功能模块完成相对独立的功能,模块与模块之间有层次性的服务关系,某些模 块提供业务无关的通用性基础服务,某些模块提供跨业务领域的基础服务,还有 一些模块提供业务领域服务功能。业务应用实现时采用规范的接口 调用方式,进 行功能模块的顺序调用。 交通集成指挥平台与子系统的集成技术路线贯彻松散耦合的原则。 交通 集成 指挥平台 需要集成的功能子系统、设备多样,各子系统的实现技术各异,各设备 提供的 SDK 技术途径不同,所以必须抽象出规范的接口定义,包括接口调用流程、 数据项和技术实现方式。对于接口调用流程和数据项,依托于业务分析、梳理、 抽象,形成标准的基础流程、信息项和扩展流程、数据项,实现弹性应对系统接 入。接口技术实现必须采用与开发工具无关和操作系统无关的技术手段,达到系 统接入技术的广泛适应性。交通集成指挥平台接口规范正是采用 此指导思想,应 用 TCP socket 通讯技术加 XML 消息体的方式并用消息总线的机制,形成大多数 的控制类应用的接口规范;部分数据交互交口采用 Web Service 技术实现;部分 数据交互采用 Oracle 数据库中间表、视图、存储过程的方式。以上三种集成技术 路线可以应对全部的集成技术需求。 第 22 页 金螳螂怡和科技 2.2.2. 技术路线 原则 系统开发技术路线 遵循如下的原则:  系统采用成熟可靠的技术路线,无论在功能还是在性能的需求上都会确保 实现的可行性,可降低 整体项目的实施的风险。  根据基础业务系统的定位和层次确定该系统选择 采用的技术路线。  智能交通集成 指挥平台 具备较强的可扩展性,为日后升级及维护奠定基 础。整个系统 具有高度的灵活性以适应不同的业务需求及不同系统配置 的需要。  智能交通集成指挥平台 接口 易于扩充和升级。接口深化设计 保证简洁,但 同时还考虑负载问题,避免因某一模块负载过大而影响整体性能。 根据 需要针对具体的接口需求和应用环境来选择最合适的接口实现技术。  对应用软件的各个功能组件、相关的性能指标, 具备完整的测试数据及性 能说明。  在软件的设计上会考虑到未来的发展,系统功能实现 模块化,使 用的程序 语言会减少将来维护及开发的困难。应用程序采用参数驱动设计,不能 确 定的因素, 做到参数化,通过对参数的设置就可适应不同的情况,不 同应用时期的要求。 集成指挥平台 可实现 多用户和多任务操作能力,并 对用户数不加限制。 2.2.3. 异构系统互操作关键技术 2.2.3.1 异构系统存在因素  商业因素 采用单一 J2EE 或者 Microsoft .NET 设计一个大型系统,将是一个代价高昂 的行为,但通常有很充分的商业原因驱使政府部门实现一个具有多个平台元素的 混合环境,从而满足其的多方面需求:如差异化业务处理,各种性能指标,多方 第 23 页 金螳螂怡和科技 面协作,固定与移动的办公环境,多种通讯方式,各种类型操作终端等。  集成因素 需要和其他已经存在系 统集成。政府部门在信息化建设过程中,已经存在很 多正在运作的信息系统,这些信息系统 很有可能是使用不同的开发平台开发的 。 由于 其内部业务逻辑复杂,如果 全部 推倒重来,会导致 很大 的系统建设开销和风 险。为了最大限度的利用现有作业信息系统,新建系统需要和现存系统进行信息 集成,充分发掘现存系统的潜力。  发展趋势因素 随着政府部门 IT 信息化的不断发展,越来越多新的解决方案会不断的出现。 政府部门会选择适合的解决方案来解决他们新的需求,新的系统与旧的系统集成 的需求,在未来会更加普遍存在。  开发模式因素 目前交警信息系统内存在基于 C/S 开发模式和基于 B/S 开发模式的应用系 统。 基于 C/S 开发模式的系统,数据存放在服务器上,业务逻辑和界面操作在客 户端应用程序上实现。 基于 B/S 开发模式的系统,数据和业务逻辑处理都存放在服务器上,客户端 的浏览器可以通过下载服务器上的应用程序得到动态扩展,服务器具有多层结构, 系统处理的数据类型可以动态扩展。 2.2.3.2 解决之道:互操作 互操作,就是通过使用行业标准或被广泛认可的数据描述和通讯协议,在采 用不同技术实现的不同平台上运行的功能单元之间进行通讯或者传输数据的能 力。 对于异构系统的互操作而言,该过程包括确保在 一个平台上构建的应用程序 第 24 页 金螳螂怡和科技 能连接到另一个平台上创建的应用程序。 互操作在各种层次中出现 ,所示。  表现层互用: 方案 A 的客户端与方案 B 的客户端直接功能调用或数据通信,实现互用。  业务逻辑层互用: J2EE 和 .NET 的业务逻辑层,均提供支持远程调用的组件,支持外部系统业 务逻辑层和表现层客户端的远程调用。第二种方式是通过构建彼此之间的消息通 道,进行信息通讯,实现互操作。  数据库共享: 两种方案通过数据库共享的形式,实现数据的交换。 2.2.3.3 异构系统实现互操作方式 解决异构系统间互操作,有三大方法:基于消息传递方法,基于远程 组件调 用方法,基于简单的数据 /文件共享方法。其中,基于消息分为基于二进制数据消 息( Binary Data)和基于封装消息方式,基于远程组件调用又分为 Web Services 方式和 CORBA 方式,下面将进行比较和详细描述。 方法 产品 /技术标准 特点 Binary Data 采用 TCP/UDP 的 Socket 包传 输;或者采用 XML 格式封 装 1.跨越异构平台、异构操作系统和各种开发工具 2.传输速度快,效率高 3.需要自定义数据格式 4.需要进行数据传输交换 5.需要对数据进行解析 6.不保障数据传输,需要额 外的编写工作来保障 Package IBM MQ , 1.降低系统间偶合度 第 25 页 金螳螂怡和科技 Message Tibco Rendenous 2.系统间异步处理 3.有效可靠传输 4.需要购买产品 Web Services 第三方标准 1.基于 HTTP/HTTPS 传输,可以跨平台调用 2.性能差 CORBA Janeva/Xbike/ NJbridg 等 1.跨平台使用 2.数据总线 3.每客户端需要额外使用 CORBA 协议 Data Sharing 1.实现最简单 2.系统间异步处理 3.系统偶合度最低 2.2.3.3.1. 消息队列 (Message Queue) MQ( Message Queue)消息队列技术是分布式应用间交换信息的一种技术。 消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过 消息队列,应用程序可独立地执行 --它们不需要知道彼此的位置、或在继续执行 前不需要等待接收程序接收此消息。 消息队列的一般以中间件形式出现。分布式应用系统借助这种中间件软件在 不同的技术之间共享资源,管理计算资源和网络通讯。消息传输中间件 (MOM), 简化了应用之间数据的传输,屏蔽底层异构操作系统和网络平台,提供一致的通 讯标准和应用开发, 确保分布式计算网络环境下可靠的、跨平台的信息传输和数 据交换。它基于消息队列的存储 -转发机制,并提供特有的异步传输机制,能够基 于消息传输和异步事务处理实现应用整合与数据交换。 目前支持消息传输的中间件产品有:  IBM Websphere MQ;  TIBCO Rendenous; 第 26 页 金螳螂怡和科技  Microsoft MQ Server(它是一个产品,不是中间件)。 除了这些产品,还有支持 JMS 通信标准的 J2EE 第三方通信组件。 2.2.3.3.2. Web Services(Web 服务 ) Web Services 是第三方标准,它的推出是为实现 Internet 上各服务之间的互 相调用。 基于浏览器的 Web 应用程序是松散耦合的,具有很强的互操作性。它们使 用 HTTP 进行通信,交换许许多多不同格式的 MIME 类型数据。 Web 服务使传 统的 Web 编程模型适用于各种应用程序,而不仅仅是基于浏览器的应用程序。 它们使用 HTTP 和其他 Internet 协议交换 SOAP 消息。由于 Web 服务依赖于 HTTP、 XML、 SOAP 和 WSDL 等行业标准,在 Internet 上展示应用程序的功 能,因此它们独立于编程语言、平台和设备。 Web Services 基础结构通过将 SOAP 消息映射到方法调用,为 Web Services 提供了简单的 API。通过提供一种非常简单的编程模型(基于将 SOAP 消息交 换映射到方法调用),它实现了此机制。 Web Services 的客户端不需要了解用于创 建它们的平台、对象模型或编程语言。而服务也不需要了解向它们发送消息的客 户端。 使用 Web Services 的唯一要求是:双方都要认可正在创建和使用的 SOAP 消息的格式,该格式是由使用 WSDL 和 XML 架构 (XSD) 表示的 Web 服务合 约定义来定义的 。 2.2.3.3.3. SOA(面向服务的体系结构) 这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务 之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组 成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存 在。而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构 是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们 第 27 页 金螳螂怡和科技 就显得非常脆弱。 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加 灵活,以适应不断变化的环境,比如经常改变的政策、业 务级别、业务重点、合 作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的 性质。我们称能够灵活地适应环境变化的业务为按需( On demand)业务,在按 需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。 虽然面向服务的体系结构不是一个新鲜事物,但它却是更传统的面向对象的 模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务,但是其整体设计却是 面向服务的。由于它考虑到了系统内的对象,所以虽然 SOA 是基于对 象的,但 是作为一个整体,它却不是面向对象的。不同之处在于接口本身。 SOA 系统原型 的一个典型例子是通用对象请求代理体系结构( Common Object Request Broker Architecture, CORBA),它已经出现很长时间了,其定义的概念与 SOA 相似。 然而,现在的 SOA 已经有所不同了,因为它依赖于一些更新的进展,这些 进展是以可扩展标记语言( eXtensible Markup Language, XML)为基础的。通过 使用基于 XML 的语言(称为 Web 服务描述语言( Web Services Description Language, WSDL))来描述接口,服务已经转到更动态且更灵活的接口系统中, 非以前 CORBA 中的接口描述语言( Interface Description Language, IDL)可比 了。 Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方 式,这样就有了面向消息的中间件( Message-Oriented Middleware)系统,比如 IBM 的 MQseries。但是为了建立体系结构模型,您所需要的并不只是服务描述。您需 要定义整个 应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作 和业务中所使用的软件的操作之间的转换点。因此, SOA 应该能够将业务的商业 流程与它们的技术流程联系起来,并且映射这两者之间的关系。例如,给供应商 付款的操作是商业流程,而更新您的零件数据库,以包括进新供应的货物却是技 术流程。因而,工作流还可以在 SOA 的设计中扮演重要的角色。 第 28 页 金螳螂怡和科技 此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与 不为您控制的外部合作伙伴进行的操作。因此,为了提高效率,您需要定义应该 如何得知服务之间的关系的策略,这种策略 常常采用服务级协定和操作策略的形 式。 最后,所有这些都必须处于一个信任和可靠的环境之中,以同预期的一样根 据约定的条款来执行流程。因此,安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。 2.2.3.3.4. Data Share 数据共享 数据共享是最简单,最早期解决系统间可用性方式,每个系统,通过以数据 库表共享或者文件共享的形式,来提供给其他系统进行读取。 J2EE 体系提供 JDBC 接口访问各种数据库, .NET 体系提供 ODBC 接口访问 数据库,异构系统只需在数据库中划分共享区,放置视图,提供给其他异构系统, 通过数据库 接口来读写。 综 上所述 , 本项目在解决异构系统互操作上采用消息队列( Message Queue) 和 Web Services( Web 服务)两种方式,其中消息队列主要实现底层的数据交互 与共享, Web Services 主要应用于 B/S 架构系统 。 2.2.4. 海量数据存储关键技术 磁盘阵列作为监控中心的视频存储设备,承担着视频数据的安全性,所以存 储设备的选型显得尤为重要。所以目前的 IP 存储很难满足带宽的需要,两种存储 架构分析如下: 2.2.4.1 网络存储系统( IP SAN、 NAS) NAS 的结构是以网络为中心,面向文件服务的。在这种存储系统中 ,应用 和数据存储部分不在同一服务器上,即有专用的应用服务器和专用的数据服务器。 其中专用数据服务器不再承担应用服务,称之为 “瘦服务器 “( Thin Server)。数据 第 29 页 金螳螂怡和科技 服务器通过局域网的接口与应用服务器连接,应用服务器将数据服务器视做网络 文件系统,通过标准 LAN 进行访问。采用 NAS 做视频监控的存储介质,由于受 网络带宽和文件系统本身的局限性,在多节点并发数据流比较大时,会造成性能 的瓶颈。 2.2.4.2 光纤存储区域网络( Storage Area Network, SAN) FC SAN 是一种以光纤通道( Fiber Channel, FC)实现服务器和存储设备之 间通讯的网络结构。 SAN 的核心是 FC,其中的服务器和存储系统各自独立,地 位平等,通过高带宽 FC 交换机相连,可避免大流量数据传输时发生阻塞和冲突。 各应用工作站通过局域网访问服务器,在各存储设备之间交换数据时可以不通过 服务器,这样就大大减轻了服务器承受的压力。 FC SAN 相对别的架构,具备很多的 特点 :  集中存取,更有效地利用存储资源  简单、集中的存储管理,降低了管理工作量,节约成本  存储设备到服务器的多对多连接方式,提高了灵活性和可扩充性  缩短了数据备份和恢复时间,提高了 吞吐量  取消了生产网络中的备份,降低了 LAN 拥塞  具备恢复能力的网络设计,为确保业务连续性提供了更高的数据可用性  卓越的可扩展性和投资保护,您可以根据业务需求轻松添加更多的存储设 备  存储环境安全性更高  无需中断业务,即可添加或重新配置存储资源 以上分析也表明, FC 存储不仅在带宽方面、在性能及扩展性方面,也是 IP 存储所不能企及的。 存储系统采用全光纤设计,通过 FC 交换机构建 FC SAN 网络,考虑到未来 节点的增加,要求存储系统扩展性较高,以满足未来扩展性的需要。并且在考虑 到用户的实际应用,如卡口、诱导屏 、信号灯、信号检测、平台数据处理、事件 主动报警等数据信息虽然数据不大,但非常关键,而且需要频繁访问,所以建议 第 30 页 金螳螂怡和科技 采用分级存储来实现数据的分层管理,对关键数据且频繁访问的数据信息建议采 用 SAS 盘进行存储,以满足频繁访问的需求,对于监控录像、电子警察等大容量 数据信息建议采用 SATA 盘进行存储,分级数据管理可实现不同应用数据的应用 价值,满足客户的需要。 同时考虑到应用的可持续性,建议一台服务器作为热备,热备服务器和其它 十几台应用服务器搭建集群系统,这样一旦其中任何一台服务器出现故障,热备 服务器可实现快速切换,保证应用 的无间断运行,最大程度的保护了客户的访问 持续性。 方案还具有以下 特点 :  强健且直观的存储管理软件保证能够最大限度地利用您的存储容量,并且 能够对您快速增长的存储环境实现完全控制。  充足有余的 I/O 通道、自动故障切换功能以及在线管理功能创造出 “永远 在线 ”式的可用性,使您的数据始终可以存取访问。  最大程度的模块化 , 从初级的配置到企业级的配置都可以保证最大程度 的互换性和兼容性。  广泛的兼容性对现有的存储网络只会产生最小的影响甚至没有影响,这样 就保护了您对底层设施的投资。  支持高性能 SAS 以及大容量的串行 ATA( SATA)磁盘驱动器混插,可以 满足主存储器和辅助存储器的要求,为 ILM 解决方案创造出一个全能 的平台  性能价格比高,传统的并行机曾经是高端 RISC 架构,生产批量小往往价 格昂贵,且维护费用高;而本集群系统采用高品质的商品化部件,其超 强的处理能力可以取代价格昂贵的中大型机,已经接近一些 MPP的水平。  可靠性高,程序运行回卷恢复系统实现了故障检测、结点软硬件瞬时/永 久故障恢复、系统动态升/降级重构等容错功能。只要有一个结点可用, 该系统就可以提供持续的服务。增加/删除结点、系统维护等操作可在 线( on-line)。  可扩展性好,结点的配置和结点机的数目可根据用户的需求来确定,原有 第 31 页 金螳螂怡和科技 的资源还可得到充分利用。当硬件与软件技术进一步发展时,可对系统 及时升级。  使用方便,系统的可视化人机交互集成开发环境功能齐全、界面友好、使 用灵便;快速消息传递系统、动态负载平衡系统、并行调试器、交互式 Fortran77 和 Fortran90 并行化编译器等软件为用户提供了方便;只要在原 有 C、 C++、 Fortran 等语言程序中的相应地方插入少量几条原语后,即 可使这些程序在集群系统上并行运行,可继承原有传统语言编写的软件 财富。 2.2.5. 交通流信息采集与发 布关键技术 2.2.5.1 交通状态的一致性描述 交通状态的一致性描述,是结合道路等级、交通环境等因素,生成描述交通 状态的指标,保证多个诱导上对同一路段交通状态的描述一致,不同道路等级上 实际道路状况与驾驶员的感受一致。具体方法如下: 已知在 T 时刻,路段 i 的流量、平均速度和占有率分别为 TiQ , TiV 和 TiOCC , 路段 i 的限速为 maxiV ,流量阈值为 Q ,占有率阈值为 OCC ,则 T 时刻路段 i 的畅通 系数为 m a x 100 100 T TTi iiT i i T T T i i i V Q Q O C C O C C C V O C C Q Q O C C O C C           , 当 或 , 当 且 TiC 是对交通状态 的定量描述, TiC 越大,交通状况越畅通。 设 jC 为拥堵阈值 , fC 为畅通阈值,则有交通状态 S= T ij T j i f T if CC C C C CC      拥 堵 , 当 缓 慢 , 当 畅 通 , 当 第 32 页 金螳螂怡和科技 通常,交通诱导系统中拥堵、缓慢、畅通三种交通状态分别对应红、黄、绿 三种颜色。对交通状态的描述可采用定性、定量两种方式,通过文字或图形发布。 2.2.5.2 诱导信息自动生成 ( 1)诱导信息表达 据调查可知,驾驶员对诱导信息的服从率 , 随着 交通状 态由畅通到拥堵逐渐 升高。 因此,诱导系统效用的发挥间接的受到交通状态描述、诱导信息表达的影 响。 本项目从系统的角度出发,以消散拥挤为第一目标,以区域总行程时间尽可 能小为第二目标,建立了双目标优化模型。在已知未来流量、 达到平衡 状态 时 的 流量、 需要卸载的流量,以及实际能够卸载的流量 的情况下 ,考虑驾驶员对诱导 信息 服从率 , 生成 描述型 、 建议型 、 加强型 三种 诱导信息表达范式 , 期望在一定 时间内逐步平稳地达到区域路网的状态均衡。具体算法如下: 令  *( 1 ) ( 1 ) ( 1 )a a au n lo a d t x t x t    为 需 要 卸 / 加 载 的 流 量 。 若 ( 1) 0aunload t ,则该路段需要向下游路段卸载流量;若 ( 1) 0aunload t , 则该路段可以由上游路段加载流量;若 ( 1) 0aunload t ,则该路段已经达到平 衡状态。 当 ( 1) 0aunload t 时,即在路段需要卸载流量的情况下,根据驾驶员对 诱导的服从率 (0 1)可知,实际能够卸载的流量为 ( 1)axt  。因此,有:  ( 1 ) ( 1 )aaun loa d t x t    ,即 * ( 1) / ( 1) 1aax t x t    时,卸载需求完全得 到满足;  ( 1 ) ( 1 )aaun loa d t x t    ,即 * ( ) / ( 1) 1aax t x t    时,卸载需求恰好得 到满足;  ( 1 ) ( 1 )aaun loa d t x t    ,即 * ( ) / ( 1) 1aax t x t    时,卸载需求得不到 第 33 页 金螳螂怡和科技 满足。 针对上述三种情况,信息的表达范式分别为: 第一范式( 1NF):若 * ( 1) / ( 1) 1aax t x t    ,则生成 “描述型 ”诱导信息; 第二范式( 2NF):若 * ( 1) / ( 1) 1aax t x t    ,则生成 “建议型 ”诱导信息; 第三范式( 3NF):若 * ( 1) / ( 1) 1aax t x t    ,则生成 “加强型 ”诱导信息。 针对信息的表达范式,生成对应的诱导策略:  描述型诱导信息:直观描述前方路段的交通状态。如 “A 至 B 行驶缓慢 ”;  建议型诱导信息:描述前方路段的交通状态,并建议绕行,但不给出绕行 路线。如 “A 至 B 行驶缓慢,请绕行 ”;  加强型诱导信息:将前方路段的交通拥堵程度升级,并给出绕行路 线。如 “A 至 B 拥堵,请绕行 C”。 交通状态由畅通到拥堵,对应的诱导服从率逐渐升高。加强型诱导信息通过 升级交通状态的拥堵程度,使服从率增加,从而尽可能满足卸载需求。绕行路线 优先选择可加载流量的路段,加载量大的路段优先级高。 ( 2)诱导信息编辑 智能化城市道路交通诱导系统,能够根据常用的诱导信息词汇生成词库,结 合 诱导屏体的大小、像素、分辨率设置对应的模板。文字形式的诱导信息,对应 词库,经系统解析后自动分词、换行,与不同模板匹配,生成符合诱导物理特性 的图片形式的诱导信息用于发布。 诱导信息编辑模板使生成诱导信息 时,只需关注信息内容,而无需关注屏体 的大小、像素、分辨率等显示屏物理特性,为用户提供了灵活、快速的信息发布 通道。 ( 3)节目单生成 通常,诱导信息发布采用“逐屏、逐信息发布”的模式,如下图所示,先选 择某块诱导,再编辑要发布的诱导信息,诱导信息以显示页形式发布。“逐屏、逐 第 34 页 金螳螂怡和科技 信息发布”的模式是诱导与显示页之间的多对多模式,随着诱导系统规模的不断 增大,该模式业务流程繁琐,难以满足实际应用的需求。 智能化城市道路交通诱导系统,采用一对多的“按节目单发布”的模式,如 下图所示,由诱导信息构成诱导显示页,多个显示页构成节目 单,节目单中定义 了显示页发布的时间、对应诱导等内容,节目单之间按优先级排序。每块诱导对 应若干节目单,系统控制诱导按顺序完成节目单中各个显示页的发布任务。 节目单的优先级由高到低分为唯一、优先、普通三类。通常,不允许其他节 目单插播的信息级别设定为唯一,事故等需要及时发布的信息级别设定为优先, 道路交通状态类信息的级别设定为普通。在信息发布时,同等级的节目单按照时 间顺序依次发布,不同等级的节目单,按照节目单的优先级进行发布。 “按节目单发布”的模式, 同一节目单可对应不同的诱导,用户不需再为 每一块诱导独立编辑显示 页,只需在节目单编辑完成后,选择需要发布的诱导即 可,有效简化用户操作,提高信息发布的便捷性和准确性。 2.2.5.3 诱导的控制策略 为了防止交通状态的微小变化引起诱导显示页的频繁改变,系统借鉴了施密 特触发器原理,生成诱导显示页控制策略,即 当 表示交通状态的畅通系数 上升或 下降时,只有当变化幅度大于设定值时 , 交通 状态 才会 发生变化。 设 dC 为变化系数, TiC 为路段 i 当前的畅通系数, 'S 为前一次诱导的显示页 状态, S 为当前显示页状态,则有: 当 'S 拥堵时,       f T i T i CC C 畅通,当 缓慢,当 拥堵,当 f T idj dj CCCC CC S 当 'S 缓慢时,       d df T idj dj C CCCCC CC S f T i T i CC C 畅通,当 缓慢,当 拥堵,当 第 35 页 金螳螂怡和科技 当 'S 畅通时,       d df T ij j C CCCC C S f T i T i CC C 畅通,当 缓慢,当 拥堵,当 2.2.6. 多尺度地理空间数据的分布式存储与管理 多尺度地理空间数据分布式存储与管理技术为建立多尺度、多数据类型数字 地理信息产品一体化存储、管理、分发与应用的分布式网络地理信息系统 , 提供 了有力的技术支撑。将地理空间数据和属性数据在关系数据库中进行一体化存储 和管理是当前数据库 GIS 领域的热点和前沿。其对推进 GIS 分布式空间数据库、 数据模型领域的研究 , 具有重要的意义。 数字地理信息产品的生产、存储、管理、分发与应用 , 主要体现于: (1)多尺度、多类型数据存储与管理方面 , 主要采用两种模式 :即基于一种基 本比例尺进行无级缩放 (如德国的数字景观模型、制图综合模型 )和采 用金字塔文 件存储方式与分层管理进行多种比例尺地图数据的一体化存储 , 目前各种商业 GIS 软件都支持这种存储方式。 (2)多种类型数据存储与管理方面 , GIS 软件基本上是矢量数据、栅格数据、 遥感图像数据分别存储和管理 , 所以围绕这个问题目前国内外正在积极开展多源 数据融合的研究 , 如融合框架的数据模型及多层数据叠置研究等。 (3)地理信息分布式存储与管理方面 , 分布式系统的物质基础是计算机互联 网。国内外科学家都在研究分布式计算、分布式处理、分布式数据库、分布式应 用等功能和跨平台、跨程序、全球化、大众化等特征的网络地理信息系 统或数据 库引擎。如 ESRI 公司的 SDE, MapInfo 公司的 SpatialWare, Oracle 公司的 SpatialCartridge、 Informix 公司的 DataBlade 等。 它们结合相应的 WebGIS 产品 , 只是实现了依赖客户机 /服务器的计算。完 全的分布式计算是一个非集中的、对等的协同计算模式 , 采用面向对象的构件技 术 , 以文档为中心的软件体系结构 , 基于分布式数据库管理系统。主要特点是解 决分布异构环境下的互操作问题 , C/S 模式与对象技术相结合和应用模块的部件 第 36 页 金螳螂怡和科技 化。目前正在研究的分布计算系统体系结构或标准有 :对象管理组织 (OMG)的共同 对象请求代理体系结构 (CORBA)、 Microsoft 的分布式对象构件模型 (DCOM)、分 布式网络体系结构 (NDA)、分布式计算环境 (DCE)、 SUN 公司的 Java 等 , 它们主 要解决功能的分布处理问题。 (4)分布式数据库系统方面 , 分布式数据库是数据库技术与网络技术紧密结 合的产物。有一组数据集 , 在物理上它们分布于计算机网络的各个结点上 , 而逻 辑上是一个整体。目前的大型通用数据库管理系统 (Oracle、 Sybase 等 )能够实现其 基本功能 , 但在地理空间数据库管理方面尚无大的进展 , 只是对单 个数据库系统 进行了空间数据存储与管理的扩展。 (5)空间数据库系统方面 , 一是对大型关系数据库系统进行扩展 , 以支持空 间数据的存储与管理如 Informix 公司的 DataBlade。二是建立面向对象的空间数 据库系统 , 从低层解决复杂空间数据的存储与管理。第一种方法见效快、可靠性 强 , 可以充分利用关系数据库的成熟技术。第二种方法能够从根本上解决地理空 间数据一体化存储和管理问题 , 而且容易与 Web 服务器结合建立 B/S 系统 , 但是 难度大 , 有许多技术还不成熟。 基于上述分析 , 多尺度地理空间信息一体化存储与管理的体系结构、空间数 据 库分布模型和存储模型、空间数据在关系数据库中一体化存储和管理技术、空 间数据库引擎 (SDE)等成为当前多尺度地理空间数据分布式存储与管理研究的重 要内容。 第 37 页 金螳螂怡和科技 2.3. 总体系统架构设计 2.3.1. 系统架构 图 2.3-1 总体系统 结构图 设计依据: 《公安交通指挥系统建设技术规范 GAT445-2010》 《公安交通指挥系统设计规范 GAT515-2011-2》 第 38 页 金螳螂怡和科技 《 公安交通指挥系统建设技术 规范 -工标网 》 ( GA/T 445-2010 ) 《 公安交通指挥系统建设技术规范 》 ( GAT445-2010) 《 公安交通指挥系统工程建设程序与要求 》 ( GA/T651) 《 公安交通指挥系统建设技术规范 》 ( GA/T445) 《 道路交通信息采集信息分类与编码 》 ( GB/T20133) 《 道路交通信息采集事件信息集 》 ( GB/T20134) 本期建设是将已建及新建的 孤立 的子系统 集成 在一个平台系统中 , 通过系统 的集成能够在一个软件下完成多个系统的显示、控制、管理, 实现“三个集成” — 集成显示,集成控制,集成管理 , 在 交警的业务 中 能够起到相互联动、相互 配合 的作用,能够大幅度的提升工作效率及交通指挥的科技化能力。 1) 集成显示 在同一个系统下,集成显示多个子系统的操作界面,可以直观的查看各个设 备所在位置,及事件的位置,使用户全面掌握及监控道路交通环境。 2) 集成控制 在同一系统下对多个子系统进行控制,不再像以往在交通处理系统联动时, 需要多人操作,打开多个系统进行配合处理, 通过系统的集成控制可以有效的节 省人力资源,并可实现系统之间的高效联动。 3) 集成管理 在同一个系统下联动多个系统的基础上,与交通管理业务结合,可在不同的 交通管理业务中 调动多个不同子系统作为辅助,能够协助管理交警在处理交通管 理、交通疏导、事件处理、警卫任务等业务的工作, 实现对交通的高效、科技化 的管理。 本期建设 采用 B/S 和 C/S 混合多层结构;采用 SOA 架构;采用 WEB 和客 户端混合 方式等。 第 39 页 金螳螂怡和科技 图 2.3-2 C/S 架构 客户端平台 效果图 图 2.3-3 B/S 架构 WEB 平台效果图 软件平台 具有以下特性 :  模块化设计;  简化软件结构;  编码和测试。 第 40 页 金螳螂怡和科技 系统 设计 具有灵活性和易扩展性,在今后业务发生变化时,模块的增加和对 模块的 修改不会 对其他模块产生影响。 软件模块的设计具有相对的独立性;软件的接口 明确、开放,应用软件设计 可实现 层次化、模块化,做到层次清晰,模块合理,对其中的模块可灵活抽取替 换,模块与模块之间关系明确,易于维护。 接口管理具有灵活性与强健性,易于 各业务系统进行灵活、安全、高效的交 互。 第 41 页 金螳螂怡和科技 2.3.2. B/S 和 C/S 混合多层结构 C / S 和 B / S 混合多层架构 优势 优势 应用 系统 应用 系统  时效性 高  客户端处理能力强  架构设计更灵活 -- 应用系统控制、数 据采集  部署维护简单方便  分布式结构  推广应用灵活 -- 应用信息发布、多 级业务管理  集成信号控制  集成视频控制  集成诱导发布  集成流量采集  ……  警情信息管理  勤务排班管理  信息发布管理  静态信息采集  …… C / S 架构 B /S 架构 第 42 页 金螳螂怡和科技 交通集成指挥平台应用需求存在 两个明显的特征:实时控制类和数据分析展示 类。对于实时控制类,用户群相对固定且数量有限(如:指挥调度,主要应用部 门为主分控两级指挥中心),要求实时响应,需要复杂的协议转换和逻辑控制,对 客户机具有了一定的数据处理和数据存储能力,所以适合采用 C/S 技术路线,实 现把应用软件的计算和数据合理地分配在客户
展开阅读全文
  语墨文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
0条评论

还可以输入200字符

暂无评论,赶快抢占沙发吧。

关于本文
本文标题:智能交通集成指挥中心建议方案.pdf
链接地址:http://www.wenku38.com/p-29015.html

                                            站长QQ:1002732220      手机号:18710392703    


                                                          copyright@ 2008-2020 语墨网站版权所有

                                                             经营许可证编号:蜀ICP备18034126号

网站客服微信
收起
展开