CN111183465B - 使用车辆轨迹数据的自适应交通控制 - Google Patents

Abstract

本申请的实施例提供了交通控制系统和方法。该交通控制系统可以包括通信接口(310)，该通信接口被配置为接收由传感器获取的车辆轨迹数据(302)和来自交通信号控制器(106)的交通控制数据(304)。该交通控制系统还可包括至少一个处理器(320)。该至少一个处理器(320)可以被配置为检测异常交通状况。该至少一个处理器(320)可以进一步被配置为基于车辆轨迹数据(302)，通过调整至少两个相位的绿信比来优化在线交通控制方案。该至少一个处理器还可以被配置为实时地将优化的在线交通控制方案提供给交通信号控制器(106)以产生交通控制信号。

Description

使用车辆轨迹数据的自适应交通控制

技术领域

本申请涉及交通控制，更具体地，涉及使用车辆轨迹数据进行自适应交通控制的系统和方法。

背景技术

交通灯控制各个方向的交通流的时间。当某个交通流方向的交通信号灯是绿色时，即南行交通左转时，其他方向的车辆停止。绿灯的长度(称为绿信比)决定每个停止方向上的交通队列将堆积多长。因此，需要根据各个方向的交通状况来控制绿灯的相位和长度。

现有的交通灯控制通常由各自的控制器在各个交通灯处执行。因此，交通信号灯不与附近的交通灯协调以控制大区域中的交通流。此外，现有的交通信号灯控制依赖于由固定传感器(例如，放置在战略位置的环路检测器、地磁检测器或视频传感器)获取的数据。然而，固定传感器提供足够交通信息的能力由于其固定性而受到限制。例如，探测器覆盖范围不足(例如，在探测器建立不充足的小城市或农村地区)和探测器损坏或故障(例如，由于进行常规检查的人力不足)可能会降低由固定传感器提供的数据的质量和数量。因此，固定传感器无法获取有关连续车速、队列长度等的可靠数据。由于需要安装的基础设施、维护和维修设备所需的劳动力等，固定传感器的数据采集也不具有成本效益。

此外，现有的交通信号灯控制也严重依赖人为干预。例如，交通状况检测和报告由警察或交通巡逻队执行。交通控制方案的记录和下载由交通工程师执行。基础设施维护(例如，固定传感器)需要由经验丰富的维护人员完成。人工任务作为现有交通控制的一部分执行，使控制不可避免地昂贵。

本申请的实施例通过使用车辆轨迹数据进行自适应交通控制的改进的方法和系统解决了上述问题。

发明内容

本申请的实施例提供了一种交通控制系统。所述交通控制系统可以包括通信接口，所述通信接口被配置为接收由传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据。所述交通控制系统还可以包括至少一个处理器。所述至少一个处理器可以被配置为检测异常交通状况。所述至少一个处理器可以进一步被配置为基于所述车辆轨迹数据，通过调整至少两个相位的绿信比来优化在线交通控制方案。所述至少一个处理器还可以被配置为实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

本申请的实施例还提供了一种交通控制方法。所述交通控制方法可以包括通过通信接口接收由传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据。所述交通控制方法可以进一步包括由至少一个处理器检测异常交通状况。所述交通控制方法还可以包括由所述至少一个处理器基于所述车辆轨迹数，通过调整至少两个相位的绿信比来据优化在线交通控制方案。此外，所述交通控制方法可以包括实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

本申请的实施例进一步提供了一种其上存储指令的非暂时性计算机可读介质，当由至少一个处理器执行时，所述指令使所述至少一个处理器执行交通控制方法。所述交通控制方法可以包括接收由传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据。所述交通控制方法可以进一步包括检测异常交通状况。所述交通控制方法还可以包括基于所述车辆轨迹数据，通过调整至少两个相位的绿信比来优化在线交通控制方案。此外，所述交通控制方法可以包括实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

应当理解，前面的一般性描述和下面的详细描述都只是示例性和说明性的，并不是对要求保护的本发明的限制。

附图说明

图1示出了根据本申请实施例的交叉口交通的示例性场景。

图2示出了根据本申请实施例的安装轨迹感测系统的示例性车辆的示意图。

图3示出了根据本申请实施例的示例性交通控制系统的框图。

图4示出了包括现有交通控制方案和优化的交通控制方案的示例性交通控制方案。

图5示出了根据本申请实施例的在检测到过饱和状况时用于在线交通控制的示例性方法的流程图。

图6示出了根据本申请实施例的在检测到溢出状况时用于在线交通控制的示例性方法的流程图。

图7示出了根据本申请实施例的用于离线交通控制的示例性方法的流程图。

具体实施方式

现将详细参考示例性实施例，其示例如附图中所示。尽可能地，在整个附图中将使用相同的附图标记来表示相同或相似的部分。

众包车辆轨迹数据可以为交通信号控制提供低成本、连续且可靠的数据源。本申请的实施例提供了一种基于轨迹数据的自适应交通信号控制系统，以周期性地(例如，每隔几天)优化日时间(TOD)表、周期长度、相位差，并实时地(例如，以秒或分钟级)优化绿信比。所公开的系统包括四个主要部分：数据获取、交通诊断、交通控制方案优化和性能评估。从车辆接收实时轨迹数据，并且从所连接的信号控制器接收交通控制数据(例如，信号参数)。交通诊断单元检测异常交通状况，例如某些路段的实时过饱和以及溢出。交通控制方案优化单元包括两个模块：1)周期性优化模块和2)实时优化模块。在一些实施例中，周期性优化模块优化指定TOD日时间表、周期长度、相位差和绿信比的离线控制方案，并周期性地用优化的控制方案替换现有的控制方案。在一些实施例中，实时优化模块通过调整不同相位的绿信比，基于车辆轨迹数据优化在线交通控制方案，并实时地向交通信号控制器提供优化的交通控制方案以生成控制信号。性能评估单元评估与交通流相关的六个性能指标。

图1示出了交叉口处的交通状况的示例性场景。如图1所示，多个车辆可以沿着交叉的道路102和103行进，并且可以通过交叉口104处的交通信号灯来控制。交叉口104可以包括在每个方向上的停止线108，其可以用作车辆停下等待绿灯的地标。应当注意的是，尽管图1中所示的交叉口104是两条道路之间的交叉口，交叉信号灯位于其中心，但这种简化是示例性的，仅用于说明的目的。本文公开的实施例适用于具有任何合适的交通灯配置的任何形式的交叉口。

交通信号灯的信令由交通信号控制器106控制。在一些实施例中，交通信号控制器106可以安装在机柜内。交通信号控制器106可以是机电控制器或固态控制器。交通信号控制器可以被配置为根据控制方案生成各种交通控制信号。在一些实施例中，除了交通信号控制器106之外，控制器机柜还可以包含其他组件，例如用于分配电力的电源板、用于确保故障安全操作的冲突监控单元、闪存转移继电器以及允许警察禁用信号的警察面板。

交通信号控制器106所根据的进行操作的交通控制方案可以包括将一天的时间划分为不同时段的TOD日时间表，这样可以对不同时段应用不同控制。例如，TOD日时间表可以包括上午5:00至上午7:00(正向早高峰时间)、上午7:00至上午9:00(正向高峰时间)、上午9:00至上午11:00(正向晚高峰时间)、上午11：00-3：00(白天交通时段)、下午3：00-下午5:00(反向早高峰时间)、下午5：00-下午7:00(反向高峰时间)、下午7：00-9：00(反向晚高峰时间)、下午9:00–上午5点(夜间交通时段)。TOD日时间表可以根据城市以及交通信号控制器106所在的特定位置而不同。

对于TOD日时间表中的每个控制时段，交通控制方案进一步按相位和阶段指定控制。与本申请一致，相位是指交通流方向。例如，交叉口104可具有12个(即4×3)车辆移动相位、一个交通流方向。这12个相位可以包括：西直行、东直行、北直行、南直行、西左转、东左转、北无转、南左转、西右转、东右转、北右转、南右转。在一些实施例中，可能存在用于其他移动例如行人、骑自行车的人、公交车道或有轨电车的额外相位。与本申请一致，阶段是一组同时移动的非冲突相位。

交通控制方案周期性地控制每个相位。与本申请一致，周期定义为完成交叉口所有移动的一个信号序列的总时间。因此，周期长度定义了完整的指示序列所需的时间。交通控制方案可以根据交通信号在该位置需要切换的频率指定周期长度，例如120秒、110秒、100秒。

交通控制方案还指定了每个周期内的绿信比。在一个周期内，信比是分配给交叉口的每个相位的时间份额。信比基于交叉口相位和预期需求来确定。信比可以以周期的百分比或以秒来表示。周期通常由绿信比、黄信比和红信比组成。交通控制方案还可以指定每个绿信比的开始时间和结束时间。另外，在实现协调相位分配的实施例中，例如，为了让司机经历绿波带，交通控制方案还可以指定相位差，该相位差是后续交通信号中协调相位之间的时间关系。相位差可以以秒或以周期长度的百分比表示。

与一些实施例一致，所公开的交通控制系统使用车辆轨迹数据，而不是使用固定传感器来获取交通数据。在一些实施例中，车辆(例如，车辆110)的车载轨迹感测系统112可用于在车辆移动时获取车辆轨迹数据。轨迹感测系统112可以是独立设备或集成在另一设备内，例如车辆、移动电话、可穿戴设备、相机等。可以预期地，轨迹感测系统112可以是任何类型的可移动设备或配备有任何合适的卫星导航模块的等效结构，其使得轨迹感测系统112能够获取轨迹数据。

例如，诸如车辆110的一些车辆可以安装轨迹感测系统112，该轨迹感测系统112可以获取包括与车辆110的移动有关的位置和时间信息的轨迹数据。该轨迹数据可以被发送到服务器130。再例如，轨迹感测系统112可以安装在由车辆(例如，车辆120)司机携带的终端设备122(例如，移动电话)中。在一些实施例中，终端设备122可以运行能够使用轨迹感测系统112收集轨迹数据的移动程序。例如，司机可以使用终端设备122来运行打车或共享出行移动应用程序，该应用程序可以包括能够控制轨迹感测系统112以获取车辆120的位置、时间、速度和/或姿态信息的软件模块。终端设备122可以与服务器130通信以将轨迹数据发送到服务器130。

图2示出了根据本申请实施例的具有轨迹感测系统112的示例性车辆110的示意图。可以预期地，车辆110可以是电动车辆、燃料电池车辆、混合动力车辆或传统的内燃机车辆。车辆110可具有车身116和至少一个车轮118。车身116可以是任何车身类型，例如运动型车辆、轿跑车、轿车、皮卡车、旅行车、运动型多功能车(SUV)、小型货车或房车。在一些实施例中，如图2所示，车辆110可以包括一对前轮和一对后轮。然而，可以预期地，车辆110可具有更多或更少的车轮或等效结构，使车辆110能够四处移动。车辆110可以被配置为全轮驱动(AWD)、前轮驱动(FWR)或后轮驱动(RWD)。在一些实施例中，车辆110可以被配置为由使用车辆的操作员操作、远程控制和/或自主控制。

如图2所示，车辆110可安装轨迹感测系统112。在一些实施例中，轨迹感测系统112可以安装或附接到车身116的外部。在一些实施例中，如图2所示，轨迹感测系统112可以安装在车身116内部。在一些实施例中，轨迹感测系统112可包括安装在车身116外部的一部分部件以及安装在车身116内部的一部分部件。可以预期地，轨迹感测系统112安装在车辆110上的方式可以不受图2中所示的示例的限制，并且可以根据轨迹感测系统112和/或车辆110中包括的传感器的类型来修改以实现期望的感测性能。

在一些实施例中，当车辆110沿着路径行进时，轨迹感测系统112可以被配置为捕获实时数据。例如，轨迹感测系统112可以包括导航单元，例如，GPS接收器和/或一个或以上IMU传感器。GPS是向GPS接收器提供位置和时间信息的全球导航卫星系统。IMU是一种电子设备，使用各种惯性传感器(如加速度计和陀螺仪、有时还有磁力计)测量并提供车辆的比力、角速率、有时还包括车辆周围的磁场。

可以预期地，轨迹感测系统112所接收信号的卫星导航系统可以是全球导航卫星系统，诸如全球定位系统(GPS)、全球导航卫星系统(GLONASS)、北斗-2导航卫星系统(BDS)或欧盟的伽利略系统。卫星导航系统也可以是区域导航卫星系统，例如北斗-1系统、印度导航星座(NAVIC)系统或准天星卫星系统(QZSS)。轨迹感测系统112可以是高灵敏度GPS接收器、传统GPS接收器、手持接收器、室外接收器或运动接收器。在一些实施例中，轨迹感测系统112可以通过辅助或增强GPS、通过中间设备(例如，发射塔或站)、或者通过可以向轨迹感测系统112发送卫星信号(例如，卫星广播微波信号)或为卫星提供轨道数据或历书(例如，基于移动站的辅助)的任何其他通信方法直接连接到卫星。

另外，轨迹感测系统112可以直接或通过车辆110和终端设备122经过网络，例如无线局域网(WLAN)、广域网(WAN)、无线网诸如无线电波、蜂窝网、卫星通信网和/或本地或短程无线网(例如，蓝牙^TM)连接到服务器130以发送车辆导航信息。

轨迹感测系统112可以与服务器130通信以直接或通过车辆110和终端设备122将所感测的轨迹数据发送到服务器130。服务器130可以是本地物理服务器、云服务器(如图1和2所示)、虚拟服务器、分布式服务器或任何其他合适的计算设备。与本申请一致，服务器130可以存储从多个车辆接收的轨迹数据的数据库，用于估计交叉口处的饱和流量。

图3示出了根据本申请实施例的示例性服务器130。与本申请一致，服务器130可以接收与一个或以上车辆相关的轨迹数据302(例如，由轨迹感测系统112获取并由车辆110或终端设备122发送到服务器130)。轨迹数据302可以包括描述车辆的运动轨迹的车辆位置和时间信息。在一些实施例中，当车辆110沿轨迹行进时，产生与车辆110的移动相关的地理空间中的轨迹。例如，轨迹数据302可以包括一系列按时间顺序排列的点，例如，p1→p2→…→pn,其中每个点由地理空间坐标集和时间戳组成，例如p＝(x，y，t)。在一些实施例中，轨迹数据302可以包括与交通控制同时获取并提供给服务器130的实时轨迹数据，以及过去获取的历史轨迹数据。

与本申请一致，服务器130可以从交通信号控制器106接收交通控制数据304。交通控制数据304可以包括由交通信号控制器106使用的现有交通控制方案的控制参数。在一些实施例中，交通控制数据304可以包括TOD日时间表，其包括各种控制时段、每个控制时段内的相位和周期长度、以及每个相位的绿信比。在一些实施例中，如果在交通灯之间使用协调相位分配，则交通控制数据304可以进一步包括指定协调的交通灯之间的时间关系的相位差。

在一些实施例中，如图3所示，服务器130可以包括通信接口310、处理器320、内存330、存储器340和显示器350。在一些实施例中，服务器130可以在单个设备中具有不同的模块，诸如集成电路(IC)芯片(实现为专用集成电路(ASIC)或现场可编程门阵列(FPGA))，或者具有专用功能的单独设备。在一些实施例中，服务器130的一个或以上组件可以位于云中，或者可替代地在单一位置(诸如车辆110内或移动设备内)或分布式位置。服务器130的组件可以在集成设备中，或者分布在不同的位置但通过网络(未示出)彼此通信。

通信接口310可以通过通信电缆、无线局域网(WLAN)、广域网(WAN)、诸如无线电波、蜂窝网络和/或本地或短程无线网络(例如，蓝牙^TM)的无线网或其他通信方法向车辆110或其组件(诸如轨迹感测系统112和/或终端设备122)发送数据和接收数据。在一些实施例中，通信接口310可以是提供数据通信连接的综合交通数字网(ISDN)卡、电缆调制解调器、卫星调制解调器或调制解调器。又例如，通信接口310可以是提供与兼容LAN的数据通信连接的局域网(LAN)卡。无线链路也可以由通信接口310实现。在这样的实现中，通信接口310可以通过网络发送和接收携带表示各种类型信息的数字数据流的电信号、电磁信号或光信号。

与一些实施例一致，通信接口310可以接收由轨迹感测系统112获取的轨迹数据302。与一些实施例一致，通信接口310还可以接收由交通信号控制器106使用的交通控制数据304。通信接口310还可以将接收的轨迹数据302和交通控制数据304提供给存储器340以便存储或提供给处理器320以进行处理。

处理器320可以包括任何适当类型的通用或专用微处理器、数字信号处理器或微控制器。处理器320可以被配置为专用于交通控制的独立处理器模块。或者，处理器320可以被配置为共享处理器模块，用于执行与交通控制无关的其他功能。

如图3所示，处理器320可以包括多个模块，例如交通诊断单元322、交通控制方案优化单元324和性能评估单元326等。这些模块(以及任何相应的子模块或子单元)可以是处理器320的硬件单元(例如，集成电路的部分)，其被设计用于与处理器320通过执行程序的至少一部分而实现的其他组件或软件单元一起使用。程序可以存储在计算机可读介质上，并且当由处理器320执行时，可以完成一个或以上的功能或操作。尽管图3示出了在一个处理器320内的所有单元322-326，但是可以预期地这些单元可以分布在彼此靠近或远离的多个处理器之间。

交通诊断单元332被配置为基于轨迹数据302检测异常交通状况。在一些实施例中，异常交通状况可以是表示特定交通流方向上的某个路段过于拥挤的过饱和状况。在一些其他实施例中，异常交通状况可以是表示在特定交通流方向上的某个路段处存在排队(例如，堵塞)的溢出状况。

交通控制方案优化单元324被配置为在检测到异常交通状况时基于轨迹数据302优化交通信号控制器106的交通控制方案。在一些实施例中，交通控制方案优化单元324可以包括周期性优化模块342，其被配置为基于历史轨迹数据来优化离线交通控制方案。交通控制方案优化单元324还可以包括实时优化模块344，其被配置为基于实时轨迹数据来优化在线交通控制方案。与本申请一致，“在线”方案是指由服务器130基于实时收集的数据生成并且由交通信号控制器106实时下载以实现的控制方案。与本申请一致，“离线”方案是指基于先前收集的数据生成的控制方案，并且由交通信号控制器106周期性地下载以替代/更新其现有的控制方案。

在一些实施例中，离线交通控制方案由周期性优化模块342通过调整TOD日时间表的控制时段、每个控制时段内的周期长度、相位、每个相位的绿信比以及两个信号灯之间的相位差来优化。另一方面，在线交通控制方案由实时优化模块344通过主要调整每个相位的绿信比来优化，其可以由服务器130确定并且由交通信号控制器106实时地实现。在一些实施例中，优化在线交通控制方案还可以包括调整两个交通灯的协调相位之间的相位差。

图4示出了包括现有交通控制方案410和优化交通控制方案420的示例性交通控制方案400。图4所示的方案410和420各自具有12个相位430，包括：相位1-西左转、相位2-东直行、相位3-北左转、相位4-南直行、相位5-东左转、相位6-西直行、相位7-南左转、相位8-北直行、相位9-东右转、相位10-南右转、相位11-西右转、以及相位12-北右转。如图4所示，周期长度440是120秒。对于每个相位，方案410/420指定周期中的绿信比。例如，对于相位6，现有的交通控制方案410指定第一个30秒是绿灯，剩余的90秒是红灯。对于相同的相位，优化交通控制方案420指定第一个28秒是绿灯，剩余的92秒是红灯。换句话说，优化交通控制方案将相位6的绿灯时间缩短了2秒。又例如，对于相位10，现有交通控制方案410指定两个绿信比：第一个从第31秒开始并持续31秒，第二个从第95秒开始并持续26秒。对于相同的相位，优化交通控制方案420将第一绿信比修改为提前2秒开始并持续相同的持续时间，并且将第二绿信比修改为提前2秒开始并持续28秒。换句话说，优化交通控制方案将相位10的绿灯时间延长2秒。

返回图3，性能评估单元236被配置为评估由交通控制方案优化单元324确定的优化交通控制方案的性能。可以应用各种评估标准。例如，可以根据公式对性能进行评级。交通诊断单元322、交通控制方案优化单元324和性能评估单元326的操作将结合图5-7更详细地描述。

内存330和存储器340可以包括被提供以存储处理器320可能需要操作的任何类型的信息的任何适当类型的大容量存储器。内存330和/或存储器340可以是易失性或非易失性、磁性、半导体、磁带、光学、可移动、不可移动或其他类型的存储设备或有形(即，非暂时性)计算机可读介质，包括但不限于ROM、闪存、动态RAM和静态RAM。内存330和/或存储器340可以被配置为存储一个或以上计算机程序，其可以由处理器320执行以执行本文公开的功能。例如，内存330和/或存储器340可以被配置为存储可以由处理器320执行以用于交通控制的程序。

内存330和/或存储器340可以进一步被配置为存储处理器320使用的信息和数据。例如，内存330和/或存储器340可以被配置为存储由轨迹感测系统112和/或终端设备122提供的轨迹数据302，以及由交通信号控制器106提供的交通控制数据304。内存330和/或存储器340还可以存储优化的交通控制方案，以及在该过程中创建的中间数据。各种类型的数据可以永久存储、周期性地删除、或者在处理每个数据帧之后立即被忽略。

处理器320可呈现各种用户界面的可视化以在显示器350上显示与优化过程有关的数据。可视化可以包括诸如用于交通控制的区域地图、绿信比图等的图形，以及文本信息。显示器350可以包括显示器诸如液晶显示器(LCD)、发光二极管显示器(LED)、等离子显示器，或者任何其他类型的显示器，并提供在显示器上呈现的用于用户输入和数据显示的图形用户界面(GUI)。显示器可以包括许多不同类型的材料，例如塑料或玻璃，并且可以是触敏的以接收来自用户的命令。例如，显示器可以包括基本刚性的，例如Gorilla Glass^TM，或基本韧性的，例如Willow Glass^TM的触敏材料。在一些实施例中，显示器350可以接收用户输入以进行某些选择，例如选择TOD日时间表的控制时段以用于优化，或者手动调整某些交通控制参数，例如周期长度、相位差或绿信比。

图5示出了根据本申请实施例的在检测到过饱和状况时用于在线交通控制的示例性方法500的流程图。图6示出了根据本申请的实施例的在检测到溢出状况时用于在线交通控制的示例性方法600的流程图。在一些实施例中，方法500和方法600可以由服务器130实现。然而，方法500和方法500不限于该示例性实施例。如下所述，方法500可以包括步骤S502-S520，并且方法600可以包括步骤602-622。应当了解的是，一些步骤可以是任选的以执行本文提供的公开内容。此外，一些步骤可以同时执行，或者以与图5或图6中所示的顺序不同的顺序执行。

在步骤S502，处理器320可以通过通信接口310从一个或以上车辆(例如，车辆110和120)或终端设备(例如，终端设备122)接收轨迹数据302。在一些实施例中，轨迹数据302可以与相对于交叉口(例如，交叉口104)的至少两个车辆运动(例如，车辆110和120)相关。例如，轨迹感测系统112可以捕获包括位置和时间信息的轨迹数据302。另外，处理器320可以接收交通控制数据304。例如，交通控制数据304可以包括交通信号控制器106使用的现有交通控制方案的参数。轨迹数据302和交通控制数据304可以存储在内存330和/或存储器340中作为用于执行交通控制的输入数据。

在步骤S504，处理器320可以基于轨迹数据302确定过饱和概率。可以针对每个交通流方向确定过饱和概率。在步骤S506中，可以将所有交通流方向的过饱和概率与饱和阈值进行比较。如果任何的过饱和概率超过饱和阈值(步骤S506：是)，则检测到过饱和状况，并且方法500前进到步骤S508。否则(步骤S506：否)，没有检测到过饱和状况，并且方法500返回到步骤S502。

在步骤S508，处理器320基于轨迹数据302确定多个候选在线交通控制方案。在一些实施例中，每个候选在线交通控制方案具有若干相位并且为每个相位指定绿信比。在一些实施例中，不同候选交通控制方案中的相同相位的绿信比是不同的。在步骤S510，使用绿信比限制来过滤候选在线交通控制方案。例如，由(最小绿信比，最大绿信比)定义的范围是基于交通信号控制器106的硬件限制和/或其控制的交通信号灯预定的。在步骤S510中可以移除具有该范围之外的绿信比的候选在线交通控制方案。

在步骤S512，处理器320可以构造成本函数。在一些实施例中，成本函数可以表示交通控制的有效性，例如最小化不同交通流方向上交通量的过饱和和/或不平衡的可能性。在一些实施例中，处理器320可以基于在步骤S504中确定的过饱和概率来确定权重，并且在成本函数中使用这些权重来对交通流方向进行加权。

在步骤S514，处理器320可以基于候选在线交通控制方案来计算成本函数的值。在步骤S516，处理器320可以将具有最高值(即，对应于最有效控制)的候选在线交通控制方案识别为优化的在线交通控制方案。可以预期地，可以使用与在步骤S512-S516中描述的示例不同的各种其他优化模型和方法来优化在线交通控制方案。例如，可以使用梯度相似或其他迭代方法来解决优化。

在步骤S518，可以实时地向交通信号控制器106提供优化的在线交通控制方案，以生成交通控制信号。在一些实施例中，优化的在线交通控制方案可以由交通信号控制器106实时下载。交通信号控制器106可以根据优化的在线交通控制方案生成控制信号，以立即实施新的控制方案。

在步骤S520，处理器320可以评估优化的在线交通控制方案的性能。在一些实施例中，在优化的在线交通控制方案生效之后，处理器320可以继续接收轨迹数据。在一些实施例中，轨迹数据可以被分类为三类：(1)没有溢出且仅有一个停止；(2)没有溢出且有两个或以上停止；以及(3)溢出。这三个类别对应于不同的交通状况。在一些实施例中，处理器320可以使用这三类轨迹数据来计算性能指数(PI)：

PI＝1/(β(x_ds)){1/N[β_1(d_1+10×n_1)+β_2(d_2+10×n_2)+β_3(d_3+10×n_3)]}(1)

其中d_i、n_i(i＝1，2，3)分别是三个类别的总延迟和总停止，β_i(i＝1，2，3)是三类轨迹各自的权重。在一些实施例中，权重可以设置为β_1＝50％、β_2＝10％、以及β_3＝1％。方法600包括类似于步骤S502的步骤S602。在步骤S604，处理器320可以基于轨迹数据302确定路段的排队比率。路段可以指两个相邻交叉口之间的道路的一部分。在一些实施例中，可以为每个交通流方向确定排队比率。在步骤S606中，可以将所有交通流方向的排队比率与溢出阈值进行比较。如果有任何排队比率超过溢出阈值(步骤S606：是)，则检测到溢出状况并且方法600前进到步骤S608。否则(步骤S606：否)，没有检测到溢出状况，并且方法600返回到步骤S602。在步骤S608，处理器320可以识别具有溢出状况的路段上游和下游的交叉口处的交通灯。例如，可以识别路段两端的两个交叉口。

步骤S610-S622可以与步骤S508-S520类似地实现，除了在方法600中，每个在线交通控制方案(候选或优化的)包括用于在步骤S608中识别的交通灯各自的子方案的集合。换句话说，由方法600优化的在线交通控制方案包括两个交通信号灯而不是单独交通信号灯的控制参数。在一些实施例中，在步骤S610，每个候选在线交通控制方案还可以指定两个交通灯之间的协调相位之间的相位差。可以在不同的候选在线交通控制方案中指定不同的相位差。在步骤S620中，可以实时地向两个交通信号灯各自的交通信号控制器提供优化在线交通控制方案的子方案。

图7示出了根据本申请实施例的用于离线交通控制的示例性方法700的流程图。在一些实施例中，方法700可以由服务器130实现。然而，方法700不限于该示例性实施例。方法700可以包括如下所述的步骤S702-S712。应当了解的是，一些步骤可以是任选的以执行本文提供的公开内容。此外，一些步骤可以同时执行，或者以与图7中所示不同的顺序执行。

在步骤S702中，处理器320可以通过通信接口310接收轨迹数据302和交通控制数据304。在一些实施例中，轨迹数据302可以是在执行方法700之前几天或几周由轨迹感测系统112获取的历史轨迹数据。在一些实施例中，交通控制数据304可以包括交通信号控制器106使用的现有交通控制方案的参数。轨迹数据302和交通控制数据304可以存储在内存330和/或存储器340中作为用于执行交通控制的输入数据。

在步骤S704中，处理器320可以优化交通控制方案的TOD日时间表中的控制时段。例如，现有的TOD日时间表可以包括上午5:00至上午7:00(正向早高峰时间)、上午7:00至上午9:00(正向高峰时间)、上午9:00至上午11:00(正向晚高峰时间)、上午11：00-3：00(白天交通时段)、下午3：00-下午5:00(反向早高峰时间)、下午5：00-下午7:00(反向高峰时时间)、下午7：00-9：00(反向晚高峰时间)、下午9:00–上午5点(夜间交通时段)的控制时段。在步骤S704中，如果历史轨迹数据显示通勤交通开始拥堵的时间比上午7点更早，处理器320可以通过将正向早高峰时间调整为上午5:00到上午6:30以及将正向高峰时间调整为上午6:30到上午9:00来优化TOD日时间表。

在步骤S706中，处理器320可以优化每个控制时段内的周期长度。例如，用于正向高峰时间的现有控制时间表的周期时段可以是120秒，并且优化周期时段可以缩短到100秒，以便更频繁地切换交通灯。在步骤S708中，处理器320可以优化两个交通灯的协调相位之间的相位差。在一些实施例中，两个交通灯可以彼此相邻。例如，可以优化相位差，使交通灯按顺序“串联”(前进)，因此车队可以通过连续的一系列绿灯(也称为绿波带)行进。在步骤S710中，处理器320可以优化绿信比，类似于步骤S508-S516。

在步骤S712中，可以将优化的离线交通控制方案提供给交通信号控制器106，以替代或更新其现有的交通控制方案。在一些实施例中，优化的离线交通控制方案可以由交通信号控制器106周期性地下载，例如每3或5天、每周、每两周、每月等。可以基于各种因素来确定下载时段，包括例如交通图在该区域周围变化的频率。交通信号控制器106可以根据优化的离线交通控制方案生成控制信号，以实现新的控制方案。

本申请的另一方面涉及一种存储指令的非暂时性计算机可读介质，所述指令在被执行时使得一个或以上处理器执行如上所述的方法。所述计算机可读介质包括易失性或非易失性、磁性、半导体、磁带、光学、可移动、不可移动或其他类型的计算机可读介质或计算机可读存储设备。例如，如本申请的计算机可读介质可以是存储设备或其上存储有计算机指令的存储模块。在一些实施例中，计算机可读介质可以是其上存储有计算机指令的盘或闪存驱动器。

显而易见，本领域普通技术人员可以对本申请的系统和相关方法进行各种修改和变化。考虑到本申请的系统和相关方法的说明书和实践，其他实施例对于本领域普通技术人员是显而易见的。

本申请中的说明书和示例的目的仅被认为是示例性的，真正的范围由以下权利要求及其等同物限定。

Claims (16)

1.一种交通控制系统，包括：

通信接口，被配置为接收由传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据；以及

至少一个处理器，被配置为：

基于所述车辆轨迹数据，检测特定交通流方向上的某个路段处于拥挤的过饱和状况；所述至少一个处理器进一步被配置为：基于所述车辆轨迹数据确定每个交通流方向的过饱和概率；当所述过饱和概率超过饱和阈值时，检测所述过饱和状况；

当检测到所述过饱和状况时，基于所述车辆轨迹数据确定至少两个候选交通控制方案中的若干相位以及每个相位对应的绿信比；

基于成本函数，计算指示所述候选交通控制方案有效性的数值；所述成本函数为使用过饱和概率确定的权重对交通流方向进行加权以表示交通控制的有效性，用于反映最小化不同交通流方向上交通量的过饱和和/或不平衡的可能性；

选择与有效性的数值中的最高值对应的所述候选交通控制方案作为优化的在线交通控制方案；以及

实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

2.根据权利要求1所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为：

基于所述过饱和概率确定各个交通流方向的权重；以及

使用所述权重优化所述在线交通控制方案，以加权所述各个交通流方向的状况。

3.根据权利要求1所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为：

基于所述车辆轨迹数据确定路段的排队比率；以及

当所述排队比率超过溢出阈值时检测溢出状况。

4.根据权利要求3所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为：

识别所述路段相邻的交叉口的交通灯；

优化所述在线交通控制方案，所述在线交通控制方案包括各个识别的交通灯的子方案的集合；以及

实时地将所述子方案提供给所述各个识别的交通灯的交通信号控制器。

5.根据权利要求1所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为，使用绿信比的预定范围来过滤所述至少两个候选交通控制方案。

6.根据权利要求4所述的交通控制系统，其特征在于，至少一个处理器进一步被配置为，通过调整两个所述识别的交通灯之间的相位差来优化所述在线交通控制方案。

7.根据权利要求1所述的交通控制系统，其特征在于，所述通信接口进一步被配置为接收历史轨迹数据，以及所述至少一个处理器进一步被配置为：

基于所述历史轨迹数据，通过调整日时间表中的控制时段以及每个控制时段内的周期长度来优化离线交通控制方案；以及

周期性地向所述交通信号控制器提供所述优化的离线交通控制方案，以替代所述交通信号控制器使用的现有方案。

8.根据权利要求7所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为，通过调整两个交通灯之间的相位差来优化所述离线交通控制方案。

9.根据权利要求7所述的交通控制系统，其特征在于，所述至少一个处理器进一步被配置为，通过调整每个控制时段内每个相位的绿信比来优化所述离线交通控制方案。

10.一种交通控制方法，包括：

通过通信接口接收传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据；

基于所述车辆轨迹数据，检测特定交通流方向上的某个路段处于拥挤的过饱和状况；所述基于所述车辆轨迹数据，检测特定交通流方向上的某个路段处于拥挤的过饱和状况，包括：基于所述车辆轨迹数据确定每个交通流方向的过饱和概率；以及当所述过饱和概率超过饱和阈值时检测所述过饱和状况；

当检测到所述过饱和状况时，由至少一个处理器基于所述车辆轨迹数据确定至少两个候选交通控制方案中的若干相位以及每个相位对应的绿信比；

基于成本函数，计算指示所述候选交通控制方案有效性的数值；所述成本函数为使用过饱和概率确定的权重对交通流方向进行加权以表示交通控制的有效性，用于反映最小化不同交通流方向上交通量的过饱和和/或不平衡的可能性；

选择与有效性的数值中的最高值对应的所述候选交通控制方案作为优化的在线交通控制方案；以及

实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

11.根据权利要求10所述的交通控制方法，其特征在于，所述方法还包括：

基于所述车辆轨迹数据确定路段的排队比率；以及

当所述排队比率超过溢出阈值时检测溢出状况。

12.根据权利要求11所述的交通控制方法，进一步包括：

识别所述路段相邻的交叉口的交通灯；

优化所述在线交通控制方案，所述在线交通控制方案包括各个识别的交通灯的子方案集合；以及

实时地将所述子方案提供给所述各个识别的交通灯的交通信号控制器。

13.根据权利要求12所述的交通控制方法，其特征在于，优化所述在线交通控制方案进一步包括调整两个所识别的交通灯之间的相位差。

14.根据权利要求10所述的交通控制方法，进一步包括：

接收历史轨迹数据；

基于所述历史轨迹数据，通过调整日时间表中的控制时段以及每个控制时段内的周期长度优化离线交通控制方案；以及

周期性地向所述交通信号控制器提供所述优化的离线交通控制方案，以替代所述交通信号控制器使用的现有方案。

15.根据权利要求14所述的交通控制方法，其特征在于，优化所述离线交通控制方案进一步包括调整每个控制时段内每个相位的绿信比。

16.一种非暂时性计算机可读介质，其上存储有指令，其特征在于，所述指令在由至少一个处理器执行时使所述至少一个处理器执行交通控制方法，所述交通控制方法包括：

接收传感器获取的车辆轨迹数据和来自交通信号控制器的交通控制数据；

基于所述车辆轨迹数据，检测特定交通流方向上的某个路段处于拥挤的过饱和状况；所述基于所述车辆轨迹数据，检测特定交通流方向上的某个路段处于拥挤的过饱和状况，包括：基于所述车辆轨迹数据确定每个交通流方向的过饱和概率；以及当所述过饱和概率超过饱和阈值时检测所述过饱和状况；

当检测到所述过饱和状况时，基于所述车辆轨迹数据确定至少两个候选交通控制方案中的若干相位以及每个相位对应的绿信比；

基于成本函数，计算指示所述候选交通控制方案有效性的数值；所述成本函数为使用过饱和概率确定的权重对交通流方向进行加权以表示交通控制的有效性，用于反映最小化不同交通流方向上交通量的过饱和和/或不平衡的可能性；

选择与有效性的数值中的最高值对应的所述候选交通控制方案作为优化的在线交通控制方案；以及

实时地将所述优化的在线交通控制方案提供给交通信号控制器以产生交通控制信号。

Images