重庆高速项目介绍.pptVIP

重庆高速项目介绍 项目目标 初始状态 实现方案 经由服务总线的消息整合传输 应急预案流程 目前状态和计划 大任务点 项目目标——业务 在常态运行下，交通运行的监视、检测以区域中心为主，在路段监控、现场监控系统的配合下，实现管辖区域范围各路段交通监控信息和监控、通信系统运行信息的采集等业务处理。 在应对重特大紧急事件时，按区域整合执法、路政、养护、救援等机构资源；联动救援、医疗、消防、情报、媒体等外部单位和系统；启动控制预案，确保区域路网内尽早发现事件、尽快落实预案，最大限度地排除障碍、控制事故、恢复交通；使监控系统从事后处置型，向事前预警、事中监视、事后评价的功能型转化。 项目目标——技术 建成SOA服务与数据交换平台，为重庆高速交通路网监控平台提供软件应用开发、部署和管理的技术支撑；大部分的系统功能（数据采集，报警，展示，预案单个步骤的执行）由西南交大用VC实现，这些软件基于SOA平台开发，部署，管理不可能。SOA平台的作用是提供数据传输（包括分发）技术支撑，提供流程执行和监控支撑。 建成覆盖总中心、区域分中心和各路段监控站的三级可靠、高效的基础监控数据的通讯网络；数据传输技术支撑，TLQ+TI ESB。 实现监控总中心、区域分中心、监控站之间监控管理相关数据的有效集成和共享；通过交大系统使用TLQ+TI ESB传输实现。不是TI做业务级的数据集成。 实现监控总中心、区域分中心、监控站的软件应用之间功能调用和业务协同目标；TI BPM实现流程执行，每一步骤的功能由较大应用实现。 有效解决监控管理应用系统和外部系统之间数据、业务交互的问题。交大应用实现和未来各种外系统的具体交互（WS除外）。 初始状态 初始状态 初始状态 初始状态 初始状态——应急处理流程 项目需求 项目需求——应急流程 项目需求——应急流程 项目需求——应急流程 项目需求——应急流程 项目需求 实现方案 实现方案——数据传输 实现方案——数据传输另一方案 数据传输方案比较 实现方案——应急流程 实现方案——应急流程 应急流程——流程定义 应急流程——流程监控和任务执行 应急流程——交互界面 应急流程——交互界面 应急流程——交互界面 应急流程——交互界面 应急流程——交互界面 应急流程——半自动活动 应急流程——半自动活动 应急流程——事后统计 目前状态和计划 消息传输 TI ESB + TLQ的方案已经设计，实现并和集成商应用集成完成。 模拟用户压力（每分钟1000条）测试稳定性，测试7，8天没有问题。 具体流程需求 没有确定，集成商负责出。 但我们对集成商直接出最终的需求不报乐观的希望。更可行的是根据目前业主的想法-编流程-demo实现-业主根据具体实现在提需求-改流程的迭代方式。 根据目前和业主的讨论，目前demo的框架“六七不离十”——可能复杂化的主要在活动超时，异常后的派生流程上。 火灾流程demo的实现（第一次迭代） 可能的流程模式（活动超时，页面联动，半自动活动）自己测试完成。 统一数据模型和集成商确定第一稿。 正在实现，计划月底完成。但和集成商应用的集成依赖集成商部分的开发也能完成。 （后续）大任务点 （通过迭代）确定具体流程 大的流程在20左右量级。但模式会和第一次迭代的火灾流程类似。 具体流程的实现 包括定制的任务处理页面。 统一数据模型继续完善。 流程统计页面的定制实现 Portal 明年会面临和GIS的集成 * 工作站控制大屏幕 流协议提供视频 或视频文件 私有协议 工作站 大屏幕 全局视图 单个隧道视图 视图/对象选择 报警信息 事件信息 全局视图 单个隧道视图 1. 监控人员看到报警信息 1.1 或监控人员在某特定视图上看到报警闪烁 2 监控人员在根据需要选取不同视图，如视频，某点具体数据等，查看周边情况。 3监控人员按照一定顺序和规则（预案）手工执行界面上的功能，如显示公告板，封闭车道灯等。 2.1 界面上的视图可以根据需要显示在大屏幕上。 3.1 应用实现的预案已经做了一定的封装，如逐个调整鼓风机+照明封装成一个预案。监控人员来看这一系列细粒度活动是一个操作。 常态： 业务功能上，目前主要是监控显示隧道相关的设备，各点视频和公示板。区域联动需要能够接入并监控管理更多的设备和系统。如：更多的路段设备，短信平台，联网收费系统等。 技术上，没有使用中间件做异地消息的传递和分发路由。集成商（西南交大）希望使用中间件实现：异地消息的可靠传递，消息的可配置分发和路由而减少甚至不需要应用定死目的。 应急： 业务上，目前对一个事件的处理局限在监控人员实现一些具体的操作，没有高层次的处理流程——什么情况下需要执行操作1、3、5，什么情况需要操作2、4、6。 这些“高层次”流程是因为区域联网而