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

专利名称：用于智能交通事故管理的方法和系统的制作方法
专利说明用于智能交通事故管理的方法和系统
背景技术：
交通管理系统在很多地域被用于检测和响应变化的交通状况。此类交通管理系统中的一个关键领域是有效的事故管理，它能帮助减少由交通事故带来的迟延和改善交通网络的效率。交通事故的有效管理可以包括对事故车辆和其它残骸的迅速移除。
事故管理是复杂的过程，涉及许多任务，比如对事故信息的及时收集、应急响应单元的位置和可用信息的知识、与相关人员的协调沟通(例如，警察、环境部门或州公园机构)、通过可变消息告示牌为驾驶员提供及时的建议，以及调整交通信号时间以减轻交通拥堵。关于这些任务的决策可根据事故的类型、位置、阻碍和对周围道路和交通流量的拥堵影响而变化。由于这些任务和相应事故场景的复杂性和变化性，当前的交通管理系统缺乏适当处理决策过程的能力。
因此，我们需要解决这些问题的方法和系统。



图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题为“IMAGEPROCESSING TECHNIQUES FOR A VIDEO BASED TRAFFICMONITORING SYSTEM AND METHODS THEREFOR”类似，其全部内容已通过参考并入。事故检测/确认单元106可以与题为“AUTOMATIC FREEWAY INCIDENT DETECTION SYSTEM ANDMETHOD USING ARTIFICIAL NEURAL NETWORK AND GENETICALGORITHMS”的美国专利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中更新方案的执行，同时更新接受方案前用户干预的数目。计算方案置信指数(confidenceindex)，该值被保存供知识库学习所用。方案置信指数定义为数个对方案的正面/负面人工干预的加权和，包括对方案元素的接受、修改或拒绝。方案置信指数定义为方案在方案元素的接受、修改和拒绝方面正面/负面用户干预的加权平均。方案置信指数是知识库212中的知识水平、推理过程的性能以及事故管理商业逻辑的任何改变的指示。在步骤316中保存方案置信指数用于将来的分析，同时还在步骤318保存基于任何事故/方案情况的更新。事故的进程可以在步骤302中被监视和获取，以及在步骤304-314中重复处理，如实时自动模式和更新需求所描述的那样。
参考图4，其示出了可用来实现图3中方法300的一些步骤的数据流400的一个实施例。在步骤402中，事故信息由通信服务器202获取(图2)。事故信息可以是归一化的输入数据格式，如下面表1所示。如果信息尚未归一化，通信服务器202或其它组件(如IME206)可以将输入信息转换成标准格式。
表1 输入事故数据抓住了事故的特征，以时间、地点、类型、损坏、拥堵长度、车道堵塞等表示。这些输入可以通过不同的方法获得，包括闭路电视或无线监视设备、SOS电话(例如，在路边放置的求助或紧急电话，有一个按键呼叫交通控制中心)或移动电话、视频/环路监测器的自动事故检测输出、探测或巡逻车辆、具有紧急服务单位、交通警察或国民防卫队的不同细节级别的无线电通信。
在步骤404中，IME206(图2)执行的特征确认过程确认事故信息。此特征确认过程辅助消除由于不充分的输入或冲突的输入使推理过程进入没有解决方案存在的状态或死锁状态的可能性。例如，特征确认过程可以使用现有的商业情报，包括可管理交通事故类型的确认和根据逻辑事故发展序列对事故时间和空间信息的确认。
在步骤406中，IME206使用判别指数执行过程，以确定是应用CBR还是RBR过程来为给定的输入事故生成方案。判别指数可以在步骤406前初始化，它是事故情况库中最能代表事故的所选事故特征的汇集(例如，在它定义的特征空间中削减的维度集)。判别指数的一个例子是具有道路名称、方向、位置代码和道路状态特征输入的函数(即，Caseindeindex＝f(Road，Directionflow，Locationcode，Laneptm))。要理解这些输入特征是为举例为目的，也可以使用许多不同的特征和特征的组合。特定特征的选择基于与方案生成过程相关的所有事故特征的分析，只要所选特征在给定问题域中代表判别因素就可选取。这些特定特征与事故情况库中的现存的事故进行比较，在本例中，成功的匹配被定义成字符串操作的完全匹配。如果匹配成功(例如，如果所给定的事故通过了判别指数)，则选择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，MorganKaufmann出版社，1993，其被并入索引)过程的方法可以用于此目的。要注意情况特征是可配置的，只有当前配置的特征被用于相似性匹配。
此外参考图6，其详细示出了相似性匹配过程的一个实施例。此过程使用相似性矩阵来保存新输入情况和一组已进行索引情况间的相似度值，在步骤602中，选择一个或多个情况。在步骤604中，该过程使用数值来计算输入情况和一个已进行索引的情况之间的相似度，该相似度定义为以数值距离表示的接近度， 其中限制 其中SMk＝第k个情况的相似度值，fi＝给定情况的特征i的归一化值，

wi＝特征i的重要度值(例如权重)，介于0和1之间，具有上述权重限制，n＝特征个数。
在步骤606中，确定所识别的相似情况中是否有任何一个情况通过预定的接受阈值(例如，是否存在成功情况)。如果情况具有可接受范围内最高的相似度值，则被识别为成功情况。当SMk＝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中的事故管理动作。
表2a 表2b 输出数据格式将不同的事故应答/管理方式映射至标准事故管理方案，事故管理方案包括交通管理命令结构阵列，由系统标识符、命令类型代码、命令参数值以及命令延迟表示。交通管理系统和命令类型可以兼容任何能够和外部接口通信的商业交通管理系统，或任何能够接收无线电信号、传真、传呼、蜂窝电话呼叫、网页访问或无线信息的基于人工的管理方式。此种控制类型的例子列在表3中。
表3 尽管前面的描述示出一个或多个实施例，本领域的专业技术人员会理解此处的形式和细节可以有不同的改变而不脱离本发明的精神和范围。例如，所述方法的不同步骤能够以不同的次序执行或顺序执行、合并、再分开、用替代步骤替换、或者完全移除。此外，在方法中示出的或在本发明中别处描述的不同功能可以合并以提供额外和/或替代功能。因此，所述权利要求应该以宽泛的、与本发明一致的方式解释。
权利要求
1.用于自动生成交通事故管理方案的方法，所述方法包含
接收表示交通事故的信息；
确认至少部分所述接收的信息以确保所述接收的信息足够用于生成所述交通事故管理方案；
使用所述接收的信息中对应于多个事故特征的判别指数来选择基于情况推理(CBR)过程或是基于规划推理(RBR)过程，以生成所述交通事故管理方案；以及
使用所选CBR或RBR过程为所述事故建模且生成所述交通事故管理方案。
2.根据权利要求1的方法，其中如果所述判别指数与多个预定情况中的至少一个情况相匹配，则选择CBR过程，如果没有匹配，选择RBR过程。
3.根据权利要求1的方法，进一步包含通过选择多个所述特征来初始化所述判别指数，其中每个特征表示在给定问题域中的一个判别因素。
4.根据权利要求1的方法，进一步包含操作所述接收的信息以用预定格式建模所述交通事故。
5.根据权利要求1的方法，进一步包含根据所述交通事故和所述生成的交通事故管理方案更新所述CBR和RBR过程中的至少一个。
6.根据权利要求1的方法，其进一步包含使用事故情况结构，所述事故情况结构包括可配置事故情况特征和事故管理方案项。
7.根据权利要求1的方法，其中使用所述CBR过程生成所述交通事故管理方案包括
匹配至少部分所述接收的信息与多个预定义事故情况以识别具有最高相似度分值的成功事故情况，其中每个预定义事故情况包括事故/方案对，所述事故/方案对包含交通事故和相应的事故管理方案；以及
如果识别到成功事故情况则选出所述成功事故情况，其中所述交通事故管理方案基于对应于所述成功事故情况的所述事故管理方案。
8.根据权利要求7的方法，进一步包含调整对应于所述成功事故情况的所述事故管理方案，使之于所述交通事故更匹配。
9.根据权利要求8的方法，其中调整所述事故管理方案包括使用规则启用过程。
10.根据权利要求8的方法，其中调整所述事故管理方案包括
比较所述接收到的信息与所述事故管理方案，以识别所述事故管理方案中与所接收信息具有最小相似度的区段；
识别具有那个特定特征的最高相似度值的另一个预定义事故情况；以及
使用所述另一个预定义事故情况中的解决方案来替换所述区段。
11.根据权利要求8的方法，进一步包含保存调整过的所述事故情况。
12.根据权利要求7的方法，进一步包含
如果有多个成功事故情况则提取与每个成功事故情况相关的激活频率，其中所述激活频率表示所述相关的成功事故情况被提取的频率；以及
选择具有最高激活频率的情况作为所述成功事故情况。
13.根据权利要求1的方法，其中使用所述RBR过程生成所述交通事故管理方案包括
从能应用于所述交通事故的至少一个规则集中识别多条相关规则，其中每条所述相关规则满足从所述接收信息中识别的条件；以及
启用所述多条相关规则中每一条规则，执行每条规则定义的动作。
14.根据权利要求13的方法，进一步包含
确定在所述交通事故中是否存在递归条件；以及
根据所述递归条件通过启用规则更新所述事故管理方案。
15.根据权利要求1的方法，进一步包含
提示用户接受所述生成的交通事故管理方案；以及
只有当所述用户接受后才执行所述交通事故管理方案。
16.根据权利要求15的方法，进一步包含计算所述交通事故管理方案的置信指数，其中所述置信指数是根据在所述用户接受所述交通事故管理方案前发生的改变数量的加权和。
17.根据权利要求1的方法，进一步包含确认所述交通事故管理方案，其中所述确认包括
确保所述交通事故管理方案中的动作类型是有效的交通管理命令；以及
识别任何在前一事故状态中执行的过期命令，并且将所述过期命令从当前交通事故管理方案中去除。
18.用于自动生成交通事故管理方案的系统，所述系统包含
数据处理服务器，其与前端设施控制单元、前端数据收集单元和事故收集/确认单元连接；
交通事故管理引擎，其与所述数据处理服务器连接；以及
由所述交通事故管理引擎执行的多条可执行指令，这些指令包括
用于接收表示交通事故的信息的指令；
用于使用与从所述接收到的信息中得到的多个特征相应的置信指数来选择基于情况推理(CBR)过程或是基于规则推理(RBR)过程以生成所述交通事故管理方案的指令；以及
用于使用所选的CBR或RBR过程生成所述交通事故管理方案的指令。
19.根据权利要求18的系统，进一步包含连接所述交通事故管理引擎到所述前端设施控制单元的交通控制网关。
20.根据权利要求18的系统，其中所述交通事故管理引擎包括
通信服务器，其用于接收表示所述交通事故的所述信息；
事故管理引擎，其用于确定选用所述CBR还是RBR过程；
CBR处理器，其与所述交通管理引擎连接，用于使用所述CBR过程生成所述交通事故管理方案；以及
RBR处理器，其与所述交通管理引擎连接，用于使用所述RBR过程生成所述交通事故管理方案。
21.根据权利要求20的系统，进一步包含连接至所述事故管理引擎的知识库存储器，其中所述知识库存储器包含由所述CBR处理器使用的多个事故情况和由所述RBR处理器使用的多条规则。
22.用于生成交通事故管理方案的交通事故管理引擎，所述引擎包含
通信服务器，用于接收表示交通事故的信息；
事故管理引擎，其使用与从所述接收到的信息中得到的多个特征相应的置信指数来选择基于情况推理(CBR)过程或是基于规则推理(RBR)过程来生成所述交通事故管理方案；以及
连接至所述事故管理引擎的装置，用于使用所述CBR过程或RBR过程生成所述交通事故管理方案；以及
连接至所述事故管理引擎的装置，用于建立和跟踪高速路到高速路和高速路到主干路的事故和方案关系。
23.根据权利要求22的交通事故管理引擎，其中使用所述CBR过程的装置包括多条可执行指令，其中包括
用于将所述接收到的信息中至少一部分与多个预定义事故情况进行匹配以识别成功事故情况的指令，其中每个预定义事故情况包括包含交通事故和对应事故管理方案的事故/方案对；以及
如果识别到成功事故情况则选择所述成功事故情况的指令，其中所述交通事故管理方案基于与所述成功事故情况相应的事故管理方案。
24.根据权利要求23的交通事故管理引擎，其中使用所述CBR过程的装置进一步包括用于调整与所述成功事故情况相对应的事故管理方案以使所述事故管理方案更匹配所接收到的信息的指令。
25.根据权利要求23的交通事故管理引擎，其中使用所述CBR过程的装置进一步包括
如果有多个成功事故情况则获取与每个成功事故情况相关的激活频率的指令，其中所述激活频率表示相关成功事故情况被采用的频繁度；以及
用于选择所述成功事故情况作为具有最高激活频率的情况的指令。
26.根据权利要求22的交通事故管理引擎，其中使用所述RBR过程的装置进一步包括多条可执行指令，这些指令包括
用于从可应用于所述交通事故的至少一个规则集中识别多条相关规则的指令，其中每条所述相关规则满足从所述接收到的信息中识别的条件；以及
启用所述多条相关规则中的每一条规则的指令。
27.根据权利要求26的交通事故管理引擎，其中使用所述RBR过程的装置进一步包括
用于确定所述交通事故中是否存在递归条件的指令；以及
用于根据所述递归条件通过启用规则来更新所述交通事故管理方案的指令。
全文摘要
本发明公开了用于自动生成交通事故管理方案的方法和系统。在一实施例中，所述方法包括接收表示交通事故的信息和确认至少部分接收的信息以确保接收的信息足够用于生成交通事故管理方案。此方法包括使用基于情况推理(CBR)过程或基于规则推理(RBR)过程的混合智能引擎、通过使用对应于事故特征的判别指数来生成交通事故管理方案。此方法配有方案生成后确认过程。此方法嵌入了使用置信指数的方案评估机制。
文档编号G06N5/00GK101111862SQ200480044863
公开日2008年1月23日 申请日期2004年12月6日 优先权日2004年12月6日
发明者歆 金, 洪金城, 黄心皓, 峰 谢, 陈绍强, 王少军, 王东云, 徐咏炜 申请人:新科电子(资讯通信系统)私人有限公司