重庆高速项目介绍

《重庆高速项目介绍》由会员分享，可在线阅读，更多相关《重庆高速项目介绍（32页珍藏版）》请在金锄头文库上搜索。

1、重庆高速项目介绍,项目目标 初始状态 实现方案 经由服务总线的消息整合传输 应急预案流程 目前状态和计划 大任务点,项目目标业务,在常态运行下，交通运行的监视、检测以区域中心为主，在路段监控、现场监控系统的配合下，实现管辖区域范围各路段交通监控信息和监控、通信系统运行信息的采集等业务处理。 在应对重特大紧急事件时，按区域整合执法、路政、养护、救援等机构资源；联动救援、医疗、消防、情报、媒体等外部单位和系统；启动控制预案，确保区域路网内尽早发现事件、尽快落实预案，最大限度地排除障碍、控制事故、恢复交通；使监控系统从事后处置型，向事前预警、事中监视、事后评价的功能型转化。,项目目标技术,建成SOA

2、服务与数据交换平台，为重庆高速交通路网监控平台提供软件应用开发、部署和管理的技术支撑；大部分的系统功能（数据采集，报警，展示，预案单个步骤的执行）由西南交大用VC实现，这些软件基于SOA平台开发，部署，管理不可能。SOA平台的作用是提供数据传输（包括分发）技术支撑，提供流程执行和监控支撑。 建成覆盖总中心、区域分中心和各路段监控站的三级可靠、高效的基础监控数据的通讯网络；数据传输技术支撑，TLQ+TI ESB。 实现监控总中心、区域分中心、监控站之间监控管理相关数据的有效集成和共享；通过交大系统使用TLQ+TI ESB传输实现。不是TI做业务级的数据集成。 实现监控总中心、区域分中心、监控站的

3、软件应用之间功能调用和业务协同目标；TI BPM实现流程执行，每一步骤的功能由较大应用实现。 有效解决监控管理应用系统和外部系统之间数据、业务交互的问题。交大应用实现和未来各种外系统的具体交互（WS除外）。,初始状态,工作站控制大屏幕,流协议提供视频 或视频文件,私有协议,初始状态,初始状态,工作站,大屏幕,初始状态,全局视图,单个隧道视图,视图/对象选择,报警信息,事件信息,初始状态应急处理流程,全局视图,单个隧道视图,1. 监控人员看到报警信息,1.1 或监控人员在某特定视图上看到报警闪烁,2 监控人员在根据需要选取不同视图，如视频，某点具体数据等，查看周边情况。,3监控人员按照一定顺序和

4、规则（预案）手工执行界面上的功能，如显示公告板，封闭车道灯等。,2.1 界面上的视图可以根据需要显示在大屏幕上。,3.1 应用实现的预案已经做了一定的封装，如逐个调整鼓风机+照明封装成一个预案。监控人员来看这一系列细粒度活动是一个操作。,项目需求,常态： 业务功能上，目前主要是监控显示隧道相关的设备，各点视频和公示板。区域联动需要能够接入并监控管理更多的设备和系统。如：更多的路段设备，短信平台，联网收费系统等。 技术上，没有使用中间件做异地消息的传递和分发路由。集成商（西南交大）希望使用中间件实现：异地消息的可靠传递，消息的可配置分发和路由而减少甚至不需要应用定死目的。 应急： 业务上，目前对

5、一个事件的处理局限在监控人员实现一些具体的操作，没有高层次的处理流程什么情况下需要执行操作1、3、5，什么情况需要操作2、4、6。 这些“高层次”流程是因为区域联网而新提出的原来的一个具体操作也是包含多个小步骤的，即他们现在说的“预案”：如隧道火灾预案1包括开隧道灯，开抽风，变车道导向标志等等。这些预案的执行目前已经由路段级业务员执行，不需要变动。 更进一步，流程出现停滞等需要能够报警，进而能够采取新的措施。 流程的执行缺乏监控：没有一个视图来表现这些处理的结果，以及整个流程的执行情况。 也有常态中接入更多系统的要求。 技术上，需要一个支持人工活动的BPM引擎来执行“高层次”流程。 需要良好的

6、，能够和已有应用界面集成的流程实例监控界面和实例中人工活动的执行界面。 需要一个统一的数据模型，将和BPM流程走向相关的数据（事件类型，级别等）和应用数据（设备数据，视频文件名等）分开，BPM只处理前一部分数据。,项目需求应急流程,快速发现信息手段：人工、自动、智能信息格式：语音、文字、图片、数据、视频信息通信：网络（数据包）、短信、传真、文本事件传递：现场单元-管理单元-决策单元-发布单元,流程传递的数据的统一数据模型支持多种格式在应用数据部分，应用处理，流程本身不处理。语音，图片，视频等使用引用。,引用的获得由应用处理。视频：独立的视频流协议，和ESB无关。文件：ESB可以转发文件，但不解

7、析。,现场单元-管理单元：ESB+MOM。 管理单元-决策单元-发布单元：流程。,项目需求应急流程,系统联动上下：底层监控路段监控区域监控总中心市交委市应急办内外：12122、交通执法、路政（救援巡逻）、救援（物资、车辆、器材）、养护、消防、医疗、环境、媒体（情报板、隧道广播、电台广播、电视、网络、定制短信、服务短信）流程：预案启动以后的流程执行、交互、反馈、调整,流程会涉及和这些部门交互的步骤。底层监控，路段监控：上报报警，接受控制。区域中心，总中心：执行，监控流程。 市交委，市应急办：向这些部门发送消息。所有步骤都可能是人工或自动。,流程会涉及和这些部门交互的步骤。所有步骤都可能是人工或自

8、动。还需要和这些系统的交互适配器（应用写而非ESB写）。,反馈：步骤和流程执行状态显示。 调整：给某个人的任务他无法执行，流程能够动态的分配给其他人。设计时包括所有可能，运行时根据实例数据走不同分支。不是用户动态修改流程定义。已跟用户解释并得到口头认可，demo出来后会跟用户具体解释。,项目需求应急流程,有效处置流程执行有监控；阶段结果有反馈；流程阻滞、中断有报警；流程结束有总结；预案数据库有更新。,流程执行监控界面。,监控界面可显示步骤执行结果业务结果。,步骤执行超时，异常去执行特定步骤（报警步骤）。,流程执行统计。,根据流程统计： 一个是某一步骤内业务逻辑的更新。 还一个是流程定义的更新。

9、 都需要持续开发（demo出来后和用户具体确认）。,项目需求应急流程,业主提出的另一个版本给出应急处理需要涉及的方面，而不是一个真正的BPM流程需求,项目需求,Portal Portal的需求尚未讨论，目前理解粗的需求是： 业务上，根本上是向公众发布涉及具体事件的信息。 前面说的系统监控，流程的监控，步骤执行等由业务员在目前界面上操作，不在Portal上展示。 未来会和GIS系统集成，如实时路况等，Portal集成界面上显示？ 领导执行的流程步骤是否会在Portal上执行？ 公众是否会通过Portal调用本系统上的功能？如发送报警信息？ 与GIS的集成 向GIS导入数据： 批量导入目前系统设备

10、信息（布告板，消防站，摄像头位置等）。和TI无关。 应急时通知GIS动态信息（事件位置等）。流程中的一个自动活动。 GIS与目前系统的动态信息集成（路况等）。可能经ESB。 从GIS获取信息： 流程中调用GIS服务，获取信息，如某点附近的消防站。 获取的信息供下游活动使用而不是流程本身使用数据限定在应用数据中，使得流程本身与GIS的耦合最小。 与GIS界面集成： GIS的界面显示本系统信息？,不太确定的需求,实现方案,TLQ实现应用点对ESB点（队列到队列）的消息的单向传输。 TI ESB实现单向消息的分发和路由。基于XML消息内容的固定字段。 目的队列名。 可以是目的队列名的数组（发送应用控

11、制，ESB实现的分发）。 目的队列群别名（ESB上配置的分发）。 Java服务直接实现XML的解析，按规则的路由和分发。由于仅需要知道XML的一个特定字段，而TI的数据绑定会全文解析XML，不用TI提供的数据绑定更高效，Java服务也更通用。 应用实现多种消息交换模式。 统计数据上传，报警信息上传，控制命令下达并获取应答，监控命令下达并持续接收数据。,实现方案数据传输,TLQ实现应用点对ESB点（队列到队列）的消息的单向传输。 TLQ的发布订阅实现单向消息的分发和路由。 应用实现多种消息交换模式。,实现方案数据传输另一方案,TLQ + ESB 发送方应用可以一个发送语句动态的发给多个接收方消息

12、中指定目的队列（组）。有的消息给节点1，2，3，另一些消息给节点4，5，6，应用决定。 ESB层可以配置基于内容的路由规则。 （虽然目前没有需求）可以更方便的增加数据处理功能。 增加ESB层，效率有所降低。,数据传输方案比较,TLQ 对每种情况必须静态的规划不同的topic，无法应用动态决定。应用层必须根据业务需求区分消息目的topic。需求发生变化需要修改应用。 无法对消息进行进一步处理。效率更高。,两种方式都可以提供消息传递，可配置的分发，路由功能。,实现方案应急流程,用户提出的原则： 不改变目前路段级预案的处理过程原来不由BPM管理，现在也不用。但本系统需要能够监控这些小预案的执行状态和

13、结果细节。 BPM流程主要解决在事件比较大时（需要区域中心确认，涉及多个小预案），将人工确认和小预案串接起来执行。 特别是小预案和人工确认执行异常（超时未完成，失败）时，能够将处理升级引发更多的处理。 区域中心能够监控流程的执行和流程中小预案执行的情况。,BPM流程定义和执行方面，框架不需要非常复杂，不涉及细粒度操作。 BPM定义步骤主要包含是人工确认和执行小预案，根据确认结果和小预案执行情况走不同的后续步骤，以及活动超时时走更多的后续步骤。 统一的数据模型除流程需要判断的数据外，携带应用数据，但流程本身不使用。 监控方面，提供更好的人工活动处理界面从流程实例运行状态图开始，监控员点击当前执行

14、活动后直接处理该活动（目前的BPM实现流程实例监控和具体人工活动处理是分离的。处理人工活动时不能直观的知道该活动所处的流程实例情况）。 监控方面，流程实例监控能够和应用逻辑接口，显示某个活动的业务处理状态。 事后统计方面，定制流程执行统计分析界面。,实现方案应急流程,火灾处理业务流程（模拟）,应急流程流程定义,火灾处理技术流程,总的流程定义，不会很复杂 （尤其是正常执行时）,人工活动超时引发额外处理,具体小预案BPM来看是一个“半自动活动”。,应急流程流程监控和任务执行,应急流程交互界面,全局视图,1. 监控人员看到报警信息点击查看事件处理，或从应急预案处理列表中选取一个具体正在执行的流程,2

15、. VC界面嵌入IE控件显示TI BPM流程实例监控,2.1 流程实例监控显示当前执行步骤。,流程监控与任务处理联动,应急流程交互界面,3-1.1. 操作员点击当前执行的人工活动来处理该任务。,3-1.2. 自定制的人工活动处理页面,应急流程交互界面,3-1.3. 操作员点击确认之前自己手工执行一些人工操作，如根据需要根据需要选取不同视图，如视频，某点具体数据等，查看周边情况。或电话去路段确认等。,单个隧道视图,页面上提示操作员需要手工执行的操作。,应急流程交互界面,3-1.4. 操作员回到任务处理视图处理任务。,3-1.5 流程实例监控显示当前执行步骤。,应急流程交互界面,3-2.1. 操作

16、员点击查看当前执行的或已经执行的活动状态/结果。,3-2.2. 自定制的活动处理页面,活动的业务状态/结果的监控,应急流程半自动活动,特点： 小预案的执行或由外系统/人执行的活动。 和这类系统的交互是机器识别的消息而非人工处理界面BPM消息通知系统做事，系统消息通知BPM做完。 这类活动的完成需要长时间。 这类活动的执行需要有超时控制。,应急流程半自动活动,方案： 半自动活动 = 发送消息自动活动 + 人工活动。外围（ESB上）做服务接收应答，模拟人工处理BPM人工活动。 原因： BPM的自动活动是同步调出的，长时间执行的活动浪费资源。 我们的BPM对自动活动无法附带超时处理。 我们的BPM对自动活动无法自动恢复。,应急流程事后统计,我们的BPM引擎已经在数据库中记录多有流程实例的执行情况。 定制统计页面对流程运行进行统计BAM。 具体需求待定。 可能的需求包括： 按时间段，流程类型查询。 统计流程运行平均耗时，最长耗时，最短耗时。 统计具体活动运行平均耗时，最长耗时，最短耗时。 统计流程中耗时最长的活动。 可以做的很漂亮柱状，饼图.,