重庆高速项目介绍

重庆高速项目介绍 项目目标 初始状态 实现方案 经由服务总线的消息整合传输 应急预案流程 目前状态和计划 大任务点 项目目标业务 在常态运行下，交通运行的监视、检测以区域中 心为主，在路段监控、现场监控系统的配合下， 实现管辖区域范围各路段交通监控信息和监控、 通信系统运行信息的采集等业务处理。 在应对重特大紧急事件时，按区域整合执法、路 政、养护、救援等机构资源；联动救援、医疗、 消防、情报、媒体等外部单位和系统；启动控制 预案，确保区域路网内尽早发现事件、尽快落实 预案，最大限度地排除障碍、控制事故、恢复交 通；使监控系统从事后处置型，向事前预警、事 中监视、事后评价的功能型转化。 项目目标技术 建成SOA服务与数据交换平台，为重庆高速交通路网监控平台提供 软件应用开发、部署和管理的技术支撑；大部分的系统功能（数据 采集，报警，展示，预案单个步骤的执行）由西南交大用VC实现， 这些软件基于SOA平台开发，部署，管理不可能。SOA平台的作用 是提供数据传输（包括分发）技术支撑，提供流程执行和监控支撑 。 建成覆盖总中心、区域分中心和各路段监控站的三级可靠、高效的 基础监控数据的通讯网络；数据传输技术支撑，TLQ+TI ESB。 实现监控总中心、区域分中心、监控站之间监控管理相关数据的有 效集成和共享；通过交大系统使用TLQ+TI ESB传输实现。不是TI 做业务级的数据集成。 实现监控总中心、区域分中心、监控站的软件应用之间功能调用和 业务协同目标；TI BPM实现流程执行，每一步骤的功能由较大应用 实现。 有效解决监控管理应用系统和外部系统之间数据、业务交互的问题 。交大应用实现和未来各种外系统的具体交互（WS除外）。 初始状态 工作站控 制大屏幕 流协议提供视频 或视频文件 私有协议 初始状态 初始状态 工作站 大屏幕 初始状态 全局视图单个隧道视图 视图/对 象选择 报警信息事件信息 初始状态应急处理流程 全局视图单个隧道视图 1. 监控人 员看到报 警信息 1.1 或监控 人员在某特 定视图上看 到报警闪烁 2 监控人员在根据需要选取 不同视图，如视频，某点具 体数据等，查看周边情况。 3监控人员按照一定顺序和规则 （预案）手工执行界面上的功 能，如显示公告板，封闭车道 灯等。 2.1 界面上的视图可以根据 需要显示在大屏幕上。 3.1 应用实现的预案已经做了一定 的封装，如逐个调整鼓风机+照明 封装成一个预案。监控人员来看这 一系列细粒度活动是一个操作。 项目需求 常态： 业务功能上，目前主要是监控显示隧道相关的设备，各点视频和公示板。区域联动需要 能够接入并监控管理更多的设备和系统。如：更多的路段设备，短信平台，联网收费系 统等。 技术上，没有使用中间件做异地消息的传递和分发路由。集成商（西南交大）希望使用 中间件实现：异地消息的可靠传递，消息的可配置分发和路由而减少甚至不需要应用定 死目的。 应急： 业务上，目前对一个事件的处理局限在监控人员实现一些具体的操作，没有高层次的处 理流程什么情况下需要执行操作1、3、5，什么情况需要操作2、4、6。 这些“高层次”流程是因为区域联网而新提出的原来的一个具体操作也是包含多个小 步骤的，即他们现在说的“预案”：如隧道火灾预案1包括开隧道灯，开抽风，变车道导 向标志等等。这些预案的执行目前已经由路段级业务员执行，不需要变动。 更进一步，流程出现停滞等需要能够报警，进而能够采取新的措施。 流程的执行缺乏监控：没有一个视图来表现这些处理的结果，以及整个流程的执行情况 。 也有常态中接入更多系统的要求。 技术上，需要一个支持人工活动的BPM引擎来执行“高层次”流程。 需要良好的，能够和已有应用界面集成的流程实例监控界面和实例中人工活动的执行界 面。 需要一个统一的数据模型，将和BPM流程走向相关的数据（事件类型，级别等）和应 用数据（设备数据，视频文件名等）分开，BPM只处理前一部分数据。 项目需求应急流程 快速发现信息手段：人 工、自动、智能 信息格式：语音、文字、图片 、数据、视频 信息通信：网络（数据包）、 短信、传真、文本 事件传递：现场单元-管理单 元-决策单元-发布单元 流程传递的数据的统一数据模 型支持多种格式在应用数 据部分，应用处理，流程本身 不处理。语音，图片，视频等 使用引用。 引用的获得由应用处理。视 频：独立的视频流协议，和 ESB无关。文件：ESB可以 转发文件，但不解析。 现场单元-管理单元： ESB+MOM。 管理单元-决策单元-发 布单元：流程。 项目需求应急流程 系统联动 上下：底层监控路段监控 区域监控总中心市 交委市应急办 内外：12122、交通执法、 路政（救援巡逻）、救援（ 物资、车辆、器材）、养护 、消防、医疗、环境、媒体 （情报板、隧道广播、电台 广播、电视、网络、定制短 信、服务短信） 流程：预案启动以后的流程 执行、交互、反馈、调整 流程会涉及和这些部门交互的步 骤。底层监控，路段监控：上报 报警，接受控制。区域中心，总 中心：执行，监控流程。 市交委，市应急办：向这些部门 发送消息。所有步骤都可能是人 工或自动。 流程会涉及和这些部门交互的步骤。 所有步骤都可能是人工或自动。还需 要和这些系统的交互适配器（应用写 而非ESB写）。 反馈：步骤和流程执行状态显示。 调整：给某个人的任务他无法执行，流程 能够动态的分配给其他人。设计时包括所 有可能，运行时根据实例数据走不同分支 。不是用户动态修改流程定义。已跟用户 解释并得到口头认可，demo出来后会跟 用户具体解释。 项目需求应急流程 有效处置 流程执行有监控； 阶段结果有反馈； 流程阻滞、中断有报警 ； 流程结束有总结； 预案数据库有更新。 流程执行监控界面。 监控界面可显示步骤执行结果 业务结果。 步骤执行超时，异常去执行特定 步骤（报警步骤）。 流程执行统计。 根据流程统计： 一个是某一步骤内业务逻辑的更 新。 还一个是流程定义的更新。 都需要持续开发（demo出来后 和用户具体确认）。 项目需求应急流程 业主提出的另一个版本给出应急处理需要涉 及的方面，而不是一个真正的BPM流程需求 项目需求 Portal Portal的需求尚未讨论，目前理解粗的需求是： 业务上，根本上是向公众发布涉及具体事件的信息。 前面说的系统监控，流程的监控，步骤执行等由业务员在目前界面上操作 ，不在Portal上展示。 未来会和GIS系统集成，如实时路况等，Portal集成界面上显示？ 领导执行的流程步骤是否会在Portal上执行？ 公众是否会通过Portal调用本系统上的功能？如发送报警信息？ 与GIS的集成 向GIS导入数据： 批量导入目前系统设备信息（布告板，消防站，摄像头位置等）。和TI无关。 应急时通知GIS动态信息（事件位置等）。流程中的一个自动活动。 GIS与目前系统的动态信息集成（路况等）。可能经ESB。 从GIS获取信息： 流程中调用GIS服务，获取信息，如某点附近的消防站。 获取的信息供下游活动使用而不是流程本身使用数据限定在应用数据中， 使得流程本身与GIS的耦合最小。 与GIS界面集成： GIS的界面显示本系统信息？ 不太确定的需求 实现方案 保留原系统两 层结构。不封 装细粒度数据 库访问。 流媒体传输保 留原链路和协 议。SOA平 台不管。 和外系统的联接 由（交大）应用 完成。ESB不直 接提供适配器连 。WS除外 和WS外系统的 联接由ESB提供 适配器实现。 GIS/Portal。 TLQ实现应用点对ESB点（队列 到队列）的消息的单向传输。 TI ESB实现单向消息的分发和 路由。基于XML消息内容的固定 字段。 目的队列名。 可以是目的队列名的数组（发送 应用控制，ESB实现的分发）。 目的队列群别名（ESB上配置的 分发）。 Java服务直接实现XML的解析 ，按规则的路由和分发。由于仅 需要知道XML的一个特定字段 ，而TI的数据绑定会全文解析 XML，不用TI提供的数据绑定更 高效，Java服务也更通用。 应用实现多种消息交换模式。 统计数据上传，报警信息上传， 控制命令下达并获取应答，监控 命令下达并持续接收数据。 实现方案数据传输 TLQ实现应用点对ESB点（ 队列到队列）的消息的单向 传输。 TLQ的发布订阅实现单向消 息的分发和路由。 应用实现多种消息交换模式 。 实现方案数据传输另一方案 TLQ + ESB 发送方应用可以一个发送 语句动态的发给多个接收 方消息中指定目的队 列（组）。有的消息给节 点1，2，3，另一些消息给 节点4，5，6，应用决定。 ESB层可以配置基于内容 的路由规则。 （虽然目前没有需求）可 以更方便的增加数据处理 功能。 增加ESB层，效率有所降 低。 数据传输方案比较 TLQ 对每种情况必须静态的规划不 同的topic，无法应用动态决定 。 应用层必须根据业务需求区分 消息目的topic。需求发生变化 需要修改应用。 无法对消息进行进一步处理。 效率更高。 两种方式都可以提供消息传递，可配置的分发，路由功能。 实现方案应急流程 用户提出的原则： 不改变目前路段级预案的处理过程原来不由BPM管理，现在也不用。 但本系统需要能够监控这些小预案的执行状态和结果细节。 BPM流程主要解决在事件比较大时（需要区域中心确认，涉及多个小预案 ），将人工确认和小预案串接起来执行。 特别是小预案和人工确认执行异常（超时未完成，失败）时，能够将处理 升级引发更多的处理。 区域中心能够监控流程的执行和流程中小预案执行的情况。 BPM流程定义和执行方面，框架不需要非常复杂，不涉及细粒度操作。 BPM定义步骤主要包含是人工确认和执行小预案，根据确认结果和小预案执行情况 走不同的后续步骤，以及活动超时时走更多的后续步骤。 统一的数据模型除流程需要判断的数据外，携带应用数据，但流程本身不使用 。 监控方面，提供更好的人工活动处理界面从流程实例运行状态图开始，监 控员点击当前执行活动后直接处理该活动（目前的BPM实现流程实例监控和具 体人工活动处理是分离的。处理人工活动时不能直观的知道该活动所处的流程 实例情况）。 监控方面，流程实例监控能够和应用逻辑接口，显示某个活动的业务处理状态 。 事后统计方面，定制流程执行统计分析界面。 火警警 监控站通讯管理服务器 区域监控工作站 自动切换报警画面 发出声光报警 添加到报警列表 报警视频切换及录像 监控员确认报 警 解除报警恢复正常状态 NO 需要进行区域调度 万开路区域调度、指挥、协调命令 区域分中心 电话通知执法大队 领导业务控制台A 云万路监控站 下发本路段火灾联动预案 通知本路段相关领导 响应区域调度指挥 命令 查看报警画面 业务电话确认 查看视频及录象 火灾报 警信号 上传 监控站通讯管理服务器 区域监控系统内部处理 (确认报警的过程) 其他处理 人工确认过程 业务电话汇报 人工 取消区域调度方案执行 通知相关 部门 取消区域调度方案执 行 自动 开始执行火灾区域调度方案 领导调度、指挥、协调命令区域监控系统的调度执行 云万路区域调度、指挥、协调命令 通知本路段执法队等相部门 响应区域调度命令情报板发布万开路火灾信 息 限制通往万开路的车流 向流程引擎应答区域命令向流程引擎应答区域命令 SOA流程 引擎开始 确认 上传火灾报警信号 、基本信息及处理 情况 启动警 确认 YES 领导业务控制台B 2分钟未响应 YES NO NO 通知相关 部门 下发自动调 度命令 高速执法部门 消防部们 医疗及环境部门 公共信息发布 电话通知消防部门 电话通知医院 向流程引擎应 答区域命令 实现方案应急流程 火灾处 理业务 流程（ 模拟） 应急流程流程定义 火灾处 理技术 流程 总的流程定 义，不会很 复杂 （尤 其是正常执 行时） 人工活动超时引发 额外处理 具体小预案BPM来 看是一个“半自动 活动”。 应急流程流程监控和任务执行 应急流程交互界面 全局视图 1. 监控人员 看到报警信 息点击查看 事件处理， 或从应急预 案处理列表 中选取一个 具体正在执 行的流程 2. VC界面嵌入IE控件显示TI BPM流程实例监控 2.1 流程实例监控显示当前执 行步骤。 流程监控与任务处理联动 应急流程交互界面 3-1.1. 操作员点击当前执行的 人工活动来处理该任务。 3-1.2. 自定制的人工活动处理 页面 应急流程交互界面 3-1.3. 操作员点击确认之前自己手 工执行一些人工操作，如根据需要 根据需要选取不同视图，如视频， 某点具体数据等，查看周边情况。 或电话去路段确认等。 单个隧道视图 页面上提示操作员需要 手工执行的操作。 应急流程交互界面 3-1.4. 操作员回到任务处理视图处 理任务。 3-1.5 流程实例监控显示当前执 行步骤。 应急流程交互界面 3-2.1. 操作员点击查看当前执 行的或已经执行的活动状态/结 果。 3-2.2. 自定制的活动处理页面 活动的业务状态/结果的监控 应急流程半自动活动 特点： 小预案的执行或由外系统/人执行的活动。 和这类系统的交互是机器识别的消息而非人工处 理界面BPM消息通知系统做事，系统消息 通知BPM做完。 这类活动的完成需要长时间。 这类活动的执行需要有超时控制。 应急流程半自动活动 方案： 半自动活动 = 发送消 息自动活动 + 人工活 动。外围（ESB上） 做服务接收应答，模 拟人工处理BPM人工 活动。 原因： BPM的自动活动是同 步调出的，长时间执 行的活动浪费资源。 我们的BPM对自动活 动无法附带超时处理 。 我们的BPM对自动活