用于智能交通事故管理的方法和系统

摘要

本发明公开了用于自动生成交通事故管理方案的方法和系统。在一实施例中，所述方法包括接收表示交通事故的信息和确认至少部分接收的信息以确保接收的信息足够用于生成交通事故管理方案。此方法包括使用基于情况推理(CBR)过程或基于规则推理(RBR)过程的混合智能引擎、通过使用对应于事故特征的判别指数来生成交通事故管理方案。此方法配有方案生成后确认过程。此方法嵌入了使用置信指数的方案评估机制。

说明书

背景技术

交通管理系统在很多地域被用于检测和响应变化的交通状况。 此类交通管理系统中的一个关键领域是有效的事故管理，它能帮助 减少由交通事故带来的迟延和改善交通网络的效率。交通事故的有 效管理可以包括对事故车辆和其它残骸的迅速移除。

事故管理是复杂的过程，涉及许多任务，比如对事故信息的及 时收集、应急响应单元的位置和可用信息的知识、与相关人员的协 调沟通(例如，警察、环境部门或州公园机构)、通过可变消息告示 牌为驾驶员提供及时的建议，以及调整交通信号时间以减轻交通拥 堵。关于这些任务的决策可根据事故的类型、位置、阻碍和对周围 道路和交通流量的拥堵影响而变化。由于这些任务和相应事故场景 的复杂性和变化性，当前的交通管理系统缺乏适当处理决策过程的 能力。

因此，我们需要解决这些问题的方法和系统。

附图说明

图1是包括智能交通事故管理引擎的交通管理系统的一个实施 例的框图。

图2是图1中的智能交通事故管理引擎架构的一个实施例的框 图。

图3是可以在图1中的系统内执行的事故管理方案自动化过程方 法的一个实施例的流程图。

图4是在图1中的系统内、实现图3中的至少部分方法用到的数 据流的一个实施例的图示。

图5是可以使用图4中的所述数据流的基于情况推理(CBR)过 程的一个实施例的流程图。

图6是图5中的CBR过程可以使用的相似性匹配过程的实施例 的流程图。

图7是图4中的数据流可以使用的基于规则推理过程的一个实施 例的流程图。

图8是图4中的数据流可以使用的交通事故管理方案确认过程的 一个实施例的流程图。

具体实施方式

本发明涉及交通事故管理，更具体的，涉及能够处理各种事故 场景的自动决策支持系统。但是，要理解下面的描述提供了许多不 同的实施例或例子。描述组件和结构的特定例子是为了简化本公 开。当然这些只是例子，目的并不是限制本发明。此外，本发明在 不同的例子中会重复参考标号和/或字母。这些重复只是为了简化 和清晰的目的，它们本身并不表明讨论的这些不同的实施例和/或 配置之间的关系。

参考图1，在一实施例中，交通管理系统100包括数个可用于检 测和响应交通事故的组件。系统100包括前端设施控制单元102，前 端数据收集单元104和事故检测/确认单元106。前端数据收集单元 104可以与公开的澳大利亚专利No.1089300题为“IMAGE PROCESSING TECHNIQUES FOR A VIDEO BASED TRAFFIC MONITORING SYSTEM AND METHODS THEREFOR”类似，其全 部内容已通过参考并入。事故检测/确认单元106可以与题为 “AUTOMATIC FREEWAY INCIDENT DETECTION SYSTEM AND METHOD USING ARTIFICIAL NEURAL NETWORK AND GENETIC ALGORITHMS”的美国专利No.6,470,261所公开的类似，其全部 内容已通过参考并入。

前端设备控制单元102、前端数据收集单元104和事故检测/确 认单元106输入数据至一个或多个中央数据处理服务器108，其进而 与智能交通事故管理引擎(iTIME)110相连。根据获得的事故、交 通流量和已收集和处理的交通设施数据，iTIME110处理输入的事 故，生成一个或多个交通控制方案以辅助减轻输入的交通事故的影 响。处理之后，信息通过交通控制网关112被发送至前端设施控制 单元102以执行交通控制方案。

后面将会详细描述，系统100支持在高级交通管理中心采用事 故管理的自动决策支持过程。例如，系统100从获得的输入数据自 动生成实时事故管理方案以及支持事故确认、方案解决和确认、以 及方案评估和知识库更新。iTIME110使用混合智能引擎，该引擎利 用根据实时事故数据的启发式方法并提出事故管理方案。根据已建 模的事故特征，可以使用基于情况推理(CBR)或基于规则推理 (RBR)过程得到解决方案。CBR过程通常用于处理特定类型和位 置的事故场景，此类场景难以应用通用处理逻辑。RBR过程通常用 于处理一般类型和位置的事故场景。这两个过程的组合实现比纯 RBR系统提供更多事故场景的覆盖，同时比纯CBR系统保持更快的 处理能力。创建判别指数(discriminate index)，混合引擎用它进行 过程识别(例如，是使用CBR还是RBR过程)，其还能够根据实时 输入的事故进程处理自动事故管理方案。

当应用CBR过程时，对于给定事故，系统100根据存储在抽象 事故情况中的经验激活推理性的事故管理方案。使用CBR过程实现 的推理过程是事故管理域专有的CBR模型。更具体的，交通事故用 情况表示，事故管理方案用解决方案表示。CBR推理过程执行事故 情况相似性匹配、情况获取、事故管理方案调整以及基于情况的学 习。相似性匹配支持在事故情况中以字符串、字符、整数、浮点 数、布尔值和日期/时间格式表示的特征集。方案调整提供两种方 法，一种使用轻量级规则集，另一种使用情况参考，来改变获取的 方案以适合给定的输入事故。当在生成的方案通过人工干预被接受 后、新的抽象事故被识别时，情况学习过程支持基于情况的更新。

当应用RBR过程时，事故管理方案可以基于启发式规则集来开 发。使用RBR过程实现的推理过程应用通用规则启用过程，配以一 个或多个为事故管理定制的综合规则集。规则启用过程使用基于事 故特征、交通设施状态和交通流量状况的启发式过程，部署递归过 程以检查方案的更新。

相应的，本发明为交通事故管理提供部分或全部自动化决策支 持过程的解决方案。自动化过程为交通管理中心提供更具效率的操 作它们的事故管理任务的方法。本发明可以采用结合CBR和RBR技 术的混合专家系统引擎，通过提供更高的场景响应率和更低的响应 时间来改善纯CBR或纯RBR系统的决策响应性能。此外，可以实现 为交通事故管理域定制的CBR处理器来避开商业逻辑中结构差异的 困难，在不同的交通管理中心面对的许多交通事故管理场景中可能 会遇到此困难。

参考图2，其示出了图1中的iTIME110的示例性架构。该架构 包括内部通信服务器202，其连接中央数据处理器204和混合事故管 理引擎(IME)206。IME206还连接CBR处理器208、RBR处理器 210以及共享知识库存储212。通信服务器202获得与特定事故相关 的交通事故和更新，发送事故管理方案。IME206能处理的交通事 故的数量或事故更新的数量没有限制，它只受硬件和/或软件造成 的技术约束。

IME206可以过滤接收的(输入)事故，将输入事故数据格式转 换成标准数据格式，根据预定的判别指数从CBR处理器208和RBR 处理器210中为方案解决选出满足要求的专家系统过程，确认方 案，并且将方案转换成支持交通设施控制协议的输出格式。CBR处 理器208和RBR处理器210是实现相应推理过程的组件，它们将在 下面详细描述。共享知识库存储212提供保存和获取情况库、规则 库和事实数据的方法。更具体的，共享知识库存储212(及相关的过 程)提供方法来保存和获取情况和规则以及事实数据。事实数据被设 计实现成通过若干存储单元来创建和跟踪一个或多个事故影响区域 以及集成高速路/主干路事故管理区域/方法之间的关系。要理解 示出的每个架构组件可以进行组合、分拆成额外的组件，或是分布 式的。例如，虽然示为一个数据库，共享知识存储212实际上可以 是多个数据库。此外，CBR处理器208和RBR处理器210可以与 IME206集成在一起。

参考图3，方法300示出了可以在例如图1的系统100中执行的 事故管理方案自动过程的一个实施例。方法300的许多步骤将在下 文详细描述。在步骤302中，可以接收或更新事故信息(如果相应的 事故在先前输入过)。此事故信息可以从例如图1中的事故检测/确 认单元106接收。在步骤304中，事故被确认，只有有效的事故才继 续处理。在步骤306中，根据事故信息制定方案，在步骤308中，制 定的方案在进行优先级处理和根据一个或多个交通设施控制协议格 式化输出前与实时交通设施信息比较进行确认。在步骤310中，显 示方案以进行检查和接受(例如，由用户做出)。方案一旦被接受， 它被发送出去在步骤312中执行(例如，通过图1中的交通控制网关 112发送至前端设施控制单元300)。

在步骤314中，方案被评估和用于更新知识库存储212(图2)， 具体如下。在本例中，此评估需要方案的激活结果返回至iTIME处 理器110(图1)。更具体的，iTIME中更新方案的执行，同时更新 接受方案前用户干预的数目。计算方案置信指数(confidence index)，该值被保存供知识库学习所用。方案置信指数定义为数个 对方案的正面/负面人工干预的加权和，包括对方案元素的接受、 修改或拒绝。方案置信指数定义为方案在方案元素的接受、修改和拒 绝方面正面/负面用户干预的加权平均。方案置信指数是知识库212 中的知识水平、推理过程的性能以及事故管理商业逻辑的任何改变 的指示。在步骤316中保存方案置信指数用于将来的分析，同时还 在步骤318保存基于任何事故/方案情况的更新。事故的进程可以 在步骤302中被监视和获取，以及在步骤304-314中重复处理，如实 时自动模式和更新需求所描述的那样。

参考图4，其示出了可用来实现图3中方法300的一些步骤的数 据流400的一个实施例。在步骤402中，事故信息由通信服务器202 获取(图2)。事故信息可以是归一化的输入数据格式，如下面表1 所示。如果信息尚未归一化，通信服务器202或其它组件(如IME 206)可以将输入信息转换成标准格式。

输入域 输入类型 Inc_serial_no 整数 Event_type 整数[0，99] T_occurrence yymmdd：hhmm格式字符串 Loc_ref1 浮点公里数 Loc_ref2 浮点公里数 Cong_ref 浮点公里数 Node1 整数[700000001，999999999] Node2 整数[700000001，999999999] Loc_type 整数[0，2] Loc_code 整数[0，2] Ramp_code 字符串 Lane 11个数字，每个在[0，3]间 Cong_status 布尔型

表1

输入事故数据抓住了事故的特征，以时间、地点、类型、损 坏、拥堵长度、车道堵塞等表示。这些输入可以通过不同的方法获 得，包括闭路电视或无线监视设备、SOS电话(例如，在路边放置的 求助或紧急电话，有一个按键呼叫交通控制中心)或移动电话、视频 /环路监测器的自动事故检测输出、探测或巡逻车辆、具有紧急服 务单位、交通警察或国民防卫队的不同细节级别的无线电通信。

在步骤404中，IME206(图2)执行的特征确认过程确认事故 信息。此特征确认过程辅助消除由于不充分的输入或冲突的输入使 推理过程进入没有解决方案存在的状态或死锁状态的可能性。例 如，特征确认过程可以使用现有的商业情报，包括可管理交通事故 类型的确认和根据逻辑事故发展序列对事故时间和空间信息的确 认。

在步骤406中，IME206使用判别指数执行过程，以确定是应用 CBR还是RBR过程来为给定的输入事故生成方案。判别指数可以在 步骤406前初始化，它是事故情况库中最能代表事故的所选事故特 征的汇集(例如，在它定义的特征空间中削减的维度集)。判别指数 的一个例子是具有道路名称、方向、位置代码和道路状态特征输入 的函数(即，Caseinde_index＝f(Road，Direction_flow，Location_code，Lane_ptm))。 要理解这些输入特征是为举例为目的，也可以使用许多不同的特征 和特征的组合。特定特征的选择基于与方案生成过程相关的所有事 故特征的分析，只要所选特征在给定问题域中代表判别因素就可选 取。这些特定特征与事故情况库中的现存的事故进行比较，在本例 中，成功的匹配被定义成字符串操作的完全匹配。如果匹配成功(例 如，如果所给定的事故通过了判别指数)，则选择CBR过程。如果 匹配失败，则选择RBR过程。

在步骤408中，要确定所选择的过程是否CBR过程。如果是， 在步骤410，CBR处理器208被用于生成方案。如果不是(例如，如 果RBR过程被选择)，在步骤412，使用RBR处理器210。

另外参考图5和图6，如果选择CBR处理器，则执行步骤410。 CBR是通过进行一个或多个推理以及根据以往的经验对推理进行调 整，为给定问题生成解决方案的技术。本发明在事故管理域特定 CBR模型中实现CBR处理器。更具体的，交通事故表示为情况，事 故管理方案表示为解决方案。事故特征的一组值定义情况相应属性 的域。以往经验用事故情况/方案组汇集代表，其可以称为抽象情 况汇集的情况库。抽象情况是包括事故场景的代表组信息的事故原 型。基于情况的推理过程为事故管理方案的生成分四个步骤作推 理，如图5所示，其中包括类似性匹配、情况获取、情况调整和情 况学习的步骤。

具体参考图5，引擎首先在启动过程加载当前情况配置。在加入 事故(步骤502)和将它建模加入情况特征的当前配置中，在步骤504 执行相似性匹配以识别最相关的情况(如成功情况)作为生成方案的 起始点。结合如Nearest-Neighborhood Matching Algorithm(最近邻居 匹配算法，参见Case-Based Reasoning，Janet Kolodner，Morgan Kaufmann出版社，1993，其被并入索引)过程的方法可以用于此目 的。要注意情况特征是可配置的，只有当前配置的特征被用于相似 性匹配。

此外参考图6，其详细示出了相似性匹配过程的一个实施例。此 过程使用相似性矩阵来保存新输入情况和一组已进行索引情况间的 相似度值，在步骤602中，选择一个或多个情况。在步骤604中，该 过程使用数值来计算输入情况和一个已进行索引的情况之间的相似 度，该相似度定义为以数值距离表示的接近度，

${\mathrm{SM}}_k=f(w_i,f_i,{\bar{f}}_i)=1-\underset{i=1}{\overset{n}{\Sigma }}{w}_i*|f_i-{\bar{f}}_i|$

其中限制：

$\underset{i=1}{\overset{n}{\Sigma }}{w}_i=1$

其中SM_k＝第k个情况的相似度值，f_i＝给定情况的特征i的归 一化值，w_i＝特征i的重 要度值(例如权重)，介于0和1之间，具有上述权重限制，n＝特 征个数。

在步骤606中，确定所识别的相似情况中是否有任何一个情况 通过预定的接受阈值(例如，是否存在成功情况)。如果情况具有可 接受范围内最高的相似度值，则被识别为成功情况。当SM_k＝1时， 表明找到了完美的匹配。要理解接受阈值可以被修改以接受更多的 情况，但这可能会导致增加许多非优选情况。如果没有情况可接 受，可以在日志中加入错误，然后过程结束。但是，如果有一个或 多个情况被接受，则过程继续至步骤610。

在步骤610中，确定接受的情况是否唯一。更具体的，当输入 情况位于多个附近区域且与这些附近区域具有相等的相似度值，成 功情况根据它的历史激活频率在步骤612中被选出(例如，被激活更 多次的情况将被选择，而不选激活不那么频繁的情况)。

在步骤614中，成功情况或多个成功情况被标记以便获取。要 注意步骤504(图5)与步骤406(图4)的搜索空间和搜索方法不同。 这两种方法的组合减少了搜索空间，增加了相似度搜索速度且保持 了参考情况的覆盖。

回到图5，在步骤506中，加载步骤504识别的成功情况(例如， 属于成功情况的事故/方案对)。这可以在任何已索引的情况库上实 现。

在步骤508中，可以修改取得的情况的解决方案(例如，修改取 得的抽象情况的事故管理方案以适合当前输入的事故)。在本例子 中，只有方案的一部分会根据它相关的商业逻辑进行修改。

可以使用两种方法调整事故管理方案。第一种方法使用规则启 用过程。为情况调整定义一组规则作用于事故属性，如事故类型。 例如，方案中可变消息告示牌的设施控制值如果出现在由取得的情 况生成的消息中，可以根据当前输入事故类型进行检查和修改。可 以使用简单逻辑过程来替换方案中一个或多个显示设施上的事故类 型。此方法可以使用具有轻权重规则集的规则引擎实现。

第二种方法在情况过程中使用，通过查找输入情况和成功情况 间具有最小相似度的域，使用相关部分解决方案替换该域。此方法 的一个限制是为调整选出的域必须不依赖其它域。例如，事故类型 域“事故”通常不依赖其它事故属性。在此情况中，成功情况中显示 “事故”的可变消息告示牌可以替换显示消息“道路施工”以对应当前 的输入情况。换句话说，过程识别出在事故管理方案中具有最低相 似度值的特征，然后从特定特征具有最高相似度值的情况中取得最 可能的部分解决方案。结合起来为输入情况得到正确的域。

第一种方法为情况调整提供更精确的过程，但需要至少部分理 解过程逻辑以定义规则集。第二种方法对过程逻辑的理解要求更 少，但依赖于在情况库的抽象情况中存在的知识数量和类型。

在步骤510中，生成方案(包括步骤508中做出的任何调整)。

再次参考图4且进一步参考图7，如果选择RBR过程则执行步 骤412。RBR技术通过使用一组预定义的条件/动作对的启发式方 法为给定问题生成解决方案，条件/动作对被称作规则，其具有“条 件＝动作”格式的规则等式。规则的条件部分置于规则等式的左边， 可以包括一个或多个模式。它用于将当前数据与规则的执行进行匹 配。规则的动作部分置于规则等式的右边，用于改变规则执行的结 果。在本发明的背景下，条件被定义为输入的事故模式或事实数 据，而动作被定义为得出的事实数据或在事故管理方案中的元素。

参考图7，其示出了使用RBR过程生成方案的方法的一个实施 例。RBR过程通常涉及上下文初始化和更新、规则集识别和获取、 规则启用和递归条件检查。在本例子中，在步骤702，当输入事故加 入至RBR处理器210时上下文初始化和更新。在步骤704中，规则 包被识别和加载。规则包为规则集提供组织结构，规则集被安排在 不同的包中(例如基于事故位置)以改善规则启用过程的性能。然后 在步骤706根据事故和激活的事实数据启用相关规则。规则启用过 程包括事故模式匹配并启用所有满足给定条件的规则直至没有更多 需要启用的规则。

在步骤708中，根据启用的规则形成一组方案元素且将其加入 数据库。在步骤710确定是否存在递归条件，如果存在，交通数据 在步骤712中更新，过程回到步骤706。会用到此递归的一个例子涉 及一个或多个需要动态调整的信号控制参数以对应在每次数据更新 间隔间的主要交通情况。递归条件激活这些调整的发生。在本例 中，图7的RBR过程使用应用程序接口(API)实现，如由法国 Gentilly的ILOG公司提供的那些API，它可以配置成与为事故管理 建立的综合规则集一块工作。但是，要理解也可以使用其它实现方 式。

再次参考图4且进一步参考图8，不管是使用步骤410的CBR 过程还是步骤412的RBR过程，数据流400前进至步骤414，其中 得到的方案被确认。具体参考图8，其示出了确认过程的一个实施 例，在步骤802中检查动作类型以确保只有当前有效的命令类型在 发送前被合并。动作是系统100中定义的一种交通管理命令，由 iTIME110执行。因为对于动态更新的事故的每个状态都提出方案， 步骤804识别在上一个事故状态执行的、需要从当前状态移除的任 何过时的命令。步骤806提出用于恢复设施至事故前控制状态的合 适命令。步骤808根据如优先级和时间延迟等因素自动生成命令执 行序列。过程810将所有命令转化成合适的子系统命令协议。

回到图4，在步骤416中，确定方案是否有效(根据步骤414)。 如果它是无效的，在步骤418发送错误代码，数据流400结束。要理 解这里可以执行额外的步骤。例如，在结束前可以执行默认方案， 错误代码可以表示提出默认方案。

如果方案是有效的，方案被发送出去，分别在步骤420和422中 被审查和输出。方案输出实现为归一化数据格式，比如下表2a和2b 示出的那样。表2a示出了事故管理方案，表2b表示了多个ITS控制 命令中的一个或表2a中的事故管理动作。

输出域 输出类型 Inc_serial_no 整型 IP_serial_no 整型 Cmd_1 结构 ... Cmd_i 结构 ... Cmd_n 结构

表2a

 Cmd_id  Sys_id  Cmd_tp  Cmd_val ...   Delay

表2b

输出数据格式将不同的事故应答/管理方式映射至标准事故管 理方案，事故管理方案包括交通管理命令结构阵列，由系统标识 符、命令类型代码、命令参数值以及命令延迟表示。交通管理系统 和命令类型可以兼容任何能够和外部接口通信的商业交通管理系 统，或任何能够接收无线电信号、传真、传呼、蜂窝电话呼叫、网 页访问或无线信息的基于人工的管理方式。此种控制类型的例子列 在表3中。

动作元素 用法 可变消息告示牌 用于为驾车者提供咨询信息；由设施 ID、图像代码ID、消息、命令延迟和执 行时间参数定义。 车道使用告示牌 用于车道使用信号管理；由设施ID、车 道信号代码、命令延迟和执行时间参数定 义。 周期时长控制 用于改变信号控制的交叉路口的操作周期 时长；由信号交叉路口ID、周期时长 值、命令延迟和执行时间参数定义。 阶段切分控制 用于改变信号控制交叉路口给定周期的操 作阶段切分(绿灯时长)；由信号交叉路 口ID、阶段ID、所需阶段的绿灯时长、 命令延迟和执行时间参数定义。 绿窗请求 用于协调一组信号控制交叉路口帮助特定 方向的交通；由一组信号控制交叉路口 ID和它们的协调阶段ID，以及命令延迟 和执行时间参数定义。 高速路交通分流 用于在高速公路出口匝道分流交通；由高 速路匝道代码、道路ID、要分流的交通 流量、命令延迟和执行时间参数定义。 通信 用于所需通信方式，包括任何通信方式， 如电话、传真或短信；由电话号码和消息 参数定义。

表3

尽管前面的描述示出一个或多个实施例，本领域的专业技术人员会 理解此处的形式和细节可以有不同的改变而不脱离本发明的精神和 范围。例如，所述方法的不同步骤能够以不同的次序执行或顺序执 行、合并、再分开、用替代步骤替换、或者完全移除。此外，在方 法中示出的或在本发明中别处描述的不同功能可以合并以提供额外 和/或替代功能。因此，所述权利要求应该以宽泛的、与本发明一 致的方式解释。