用于动态管理穿梭车队的系统和方法与流程
这里提供的引言用于总体上呈现本发明的背景。当前署名的发明人的工作，就其在该背景部分描述的程度以及说明书的其他方面，既不明确地也不隐含地被认为是针对本发明的现有技术。
本发明涉及用于管理被包括为穿梭服务的一部分的穿梭车的系统和方法，并且更具体地，涉及用于根据目标目的地到达时间来优化穿梭路线的系统和方法。
穿梭和共享乘坐系统允许用户请求从上车地点到下车地点的运输。这些系统通常包括用于为用户的运输请求提供服务的人工操作穿梭车队(例如，汽车、货车、公共汽车、自行车、摩托车等)。
穿梭和共享乘坐系统根据以下一个或多个标准确定分配哪辆穿梭车以满足特定的运输请求：(i)所请求的上车地点与穿梭车之间的距离和/或(ii)穿梭车能够多快到达与该运输请求相关联的上车地点。通常，能够在最短时间内到达与运输请求相关联的上车地点的穿梭车是被分配用于服务该运输请求的穿梭车。
技术实现要素：
在一个特征中，提供了一种系统。该系统可包括通信模块、穿梭车分配模块和预订确认模块。通信模块可以被配置为获取穿梭车预订请求、穿梭车信息和运输网络状态信息。穿梭车预订请求可以从用户设备获取，并且可以包括目标目的地到达时间、上车地点和/或目的地位置。穿梭车信息可以从穿梭车队中的每辆穿梭车获取，并且可以包括与穿梭车队中的每辆穿梭车相关联的标识信息、位置信息和占用信息。运输网络状态信息可以包括与含有上车地点的地理区域相关联的交通信息和天气信息。穿梭车分配模块可以被配置为基于穿梭车预订请求、穿梭车信息和运输网络状态信息生成穿梭路线信息。穿梭路线信息可以包括指示穿梭车在上车地点接载乘客并在目标目的地到达时间之前将该乘客运输至目的地位置的指令。预订确认模块可以被配置为基于穿梭车预订请求、穿梭车信息和运输网络状态信息确定预计的目的地到达时间。另外，预订确认模块可以被配置为生成包括该预计目的地到达时间的预订确认。通信模块可以被配置为将穿梭路线信息发送至穿梭车，并且将预订确认发送至用户设备。
在另一特征中，所述系统包括缓冲生成模块。缓冲生成模块可以被配置为息获取穿梭路线信息和运输网络状态信息，并且基于该穿梭路线信息和运输网络状态信生成缓冲时间。在上述特征的一个示例中，预订确认模块还被配置为基于缓冲时间确定预计目的地到达时间。在上述特征的另一示例中，缓冲生成模块还被配置为基于穿梭路线信息和/或运输网络状态信息生成更新后缓冲时间。在上述特征的一个示例中，预定确认模块还被配置为基于更新后缓冲时间确定更新后预计目的地到达时间并生成更新后预定确认。更新后预定确认可以包括更新后预计目的地到达时间。在上述特征的又一示例中，其中通信模块还可被配置为将更新后预订确认发送至用户设备。
在一个特征中，穿梭车信息包括座位配置信息，该座位配置信息描述了与穿梭车队中每辆穿梭车相关联的可能的座位布置。在上述特征的一个示例中，穿梭车分配模块还可以被配置为基于座位配置信息生成穿梭路线信息。
在另一个特征中，运输网络状态信息还可以包括固定运输状态信息，该固定运输状态信息描述了与含有上车地点的地理区域相关联的固定路线运输网络中包含的车辆的相应状态。
在一个特征中，穿梭车包括自动驾驶车辆。在该特征中，穿梭路线信息可以被配置为使自动驾驶车辆在上车地点接载乘客并在目标目的地到达时间之前将该乘客运输至目的地位置。
在一个特征中，穿梭车分配模块还可以被配置为基于穿梭车预订请求、穿梭车信息和/或运输网络状态信息从穿梭车队中选择特定穿梭车以满足预订请求。
在另一个特征中，预订确认还包括所分配的穿梭车标识信息。所分配的穿梭车标识信息可以包括标识穿梭车队中被分配以满足预订请求的特定穿梭车的信息。
在一个特征中，预订确认还包括上车地点确认信息。上车地点确认信息可以包括上车地点的文本和视觉表示中的至少一个。
在一个特征中，预订确认模块还可以被配置为基于穿梭车预订请求、穿梭车信息和/或运输网络状态信息的改变来确定更新后预计目的地到达时间。在上述特征的一个示例中，预订确认模块还可以被配置为生成更新后预订确认。更新后预定确认可以包括更新后预计目的地到达时间。在上述特征的又一示例中，通信模块还可以被配置为将更新后预订确认发送至用户设备。
在一个特征中，穿梭车分配模块还可以被配置为基于穿梭车预订请求、穿梭车信息和/或运输网络状态信息的改变生成更新后穿梭路线信息。
在另一个特征中，通信模块还可以被配置为将更新后穿梭路线信息发送至穿梭车。
在一个特征中，所述系统还包括穿梭车。
在另一特征中，该系统还包括穿梭车队。
本发明的其他应用领域将从具体实施方式、权利要求书和附图中变得显而易见。详细描述和具体示例仅用于说明的目的，并不旨在限制本发明的范围。
附图说明
根据具体实施方式和附图将对本发明有更充分理解，其中：
图1是例示了用于管理穿梭车队的系统的示例性网络图；
图2是例示了用于管理穿梭车队的计算设备的示例性功能框图；
图3是例示了用于管理穿梭车队的系统的示例性功能框图，并且包括用于与该系统一起使用的计算设备的另一示例；
图4是例示了包含被配置为获取穿梭车预订请求的图形用户界面(gui)的用户设备的示例图；
图5是例示了包含被配置为确认穿梭车预订请求并提供预计目的地到达时间的gui的用户设备的示例图；
图6是例示了用于管理多个穿梭车预订请求的示例性过程的状态图和附表；以及
图7是例示了用于管理穿梭车队的示例性方法的流程图。
在附图中，附图标记可以被重复使用以标识类似和/或同样的元件。
具体实施方式
现在参照图1，示出了用于管理穿梭车队104的系统100。系统100包括一个或多个用户设备102、穿梭车队104、穿梭车管理计算设备108、道路交通计算设备110、天气计算设备112和固定路线运输网络计算设备114。道路交通计算设备110、天气计算设备112和固定路线运输网络计算设备114可以使用领域内已知的通信协议通过一个或多个有线或无线网络106连接至穿梭车管理计算设备108。类似地，穿梭车管理计算设备108可以经由一个或多个有线或无线网络106连接至用户设备102中的每个用户设备(例如，用户设备102a)以及穿梭车队104中的每辆穿梭车(例如，穿梭车104a)。
用户设备102中的每个用户设备(例如，用户设备102x)可以包括能够通过网络106与穿梭车管理计算设备108进行通信的适合的电子设备。通过示例的方式而非限制，用户设备102可以包括智能电话、平板、移动电话、膝上型计算机、台式计算机、个人数字助手、电子书或者领域内已知的且能够执行本文所述功能的任意其他适合的电子设备。
穿梭车队104中的每辆穿梭车(例如，穿梭车104x)可以包括能够完成以下操作的任意适合的车辆：(i)通过网络106与穿梭车管理计算设备108进行通信，以及(ii)将一个或多个乘客从第一地点(例如，上车地点)运输至第二地点(例如，目的地或下车地点)。根据一些示例，穿梭车可以包括汽车、货车、公共汽车、自行车、摩托车、火车、电车、轮渡等。根据一个示例，穿梭车104包括自动驾驶车辆，该自动驾驶车辆被配置为基于从穿梭车管理计算设备108接收到的指令沿着特定路线行驶和/或进行特定停靠。
道路交通计算设备110可以包括通过网络106连接至穿梭车管理计算设备108的一个或多个计算设备(例如，服务器计算机等)。根据一个示例，道路交通计算设备110可以被配置为生成与含有上车地点的地理位置相关联的交通信息，该上车地点是从用户设备(例如，用户设备102a)接收的穿梭车预订请求的一部分。该交通信息可以包括对于地理位置内的一条或多条道路的交通状况的描述。根据一个示例，地理位置可以另外包含作为穿梭车预订请求的一部分从用户设备接收的目的地或下车地点。此外，交通状况可以定量地表达(例如，以1到10的等级，其中1是轻交通状况，10是重交通状况)、定性地表达(例如，“轻”、“中”或“重”)或者通过领域内已知的任意其他适合的惯例来表达。
天气计算设备112可以包括通过网络106连接至穿梭车管理计算设备108的一个或多个计算设备(例如，服务器计算机等)。根据一个示例，天气计算设备112可以被配置为生成与含有上车地点的地理位置相关联的天气信息，该上车地点是从用户设备(例如，用户设备102a)接收的穿梭车预订请求的一部分。天气信息可以包括对于该地理位置处和/或其周围的天气状况的描述。根据一个示例，地理位置可以另外包含作为穿梭车预订请求的一部分从用户设备接收的目的地或下车地点。此外，天气状况可以定量地表达(例如，通过一个或多个温度、气压和/或湿度读数)、定性地表达(例如，“下雨”、“冰雹”、“雨夹雪”、“雪”、“大风”、“极度炎热”、“极度寒冷”等)或者通过领域内已知的任意其他适合的惯例来表达。
固定路线运输网络计算设备114可以包括通过网络106连接至穿梭车管理计算设备108的一个或多个计算设备(例如，服务器计算机等)。根据一个示例，固定路线运输网络计算设备114可以被配置为生成描述固定路线运输网络中包含的车辆的相应信息的固定路线运输状态信息，该固定路线运输网络与含有作为穿梭车预订请求的一部分从用户设备(例如，用户设备102a)接收的上车地点(或者，在一些示例中，也可以是目的地或下车地点)的地理位置相关联。固定路线运输网络中包含的车辆可以包括根据作为固定路线运输网络的一部分的预定时间表运行的车辆，例如但不限于，火车、公共汽车、轮渡、飞机等。固定路线运输状态信息可以包括对于与地理位置相关联的固定路线运输网络中包含的车辆的状态描述。作为示例而非限制，固定路线运输状态信息可以指示车辆是按时运行还是经历延迟、任意延迟的预计长度、引起任何延迟的任何事件的性质等。
交通信息、天气信息和/或固定路线运输状态信息在本文中可以统称为“运输网络状态信息116”。如下面更详细描述的，运输网络状态信息116可以由穿梭车管理计算设备108利用以(i)优化和动态调整穿梭车104的管理，以及(ii)通过提供高准确性的预计目的地到达时间等来提升用户体验。
图2示出了计算设备108的示例。为简单起见，图2中仅描绘了单个计算设备108。但是，应该理解，图1的分布式网络系统100可以包括采用与关于图2的计算设备108所阐述的架构相同或相似的架构的一个或多个计算设备108。在一个示例中，计算设备108是服务器计算机。计算设备108通常包括一个或多个cpu或处理器170、一个或多个输入设备172(例如，键盘、触摸板、鼠标等)、包括显示器176的显示子系统174、网络接口178、存储器180和块存储182。
网络接口178将计算设备108经由网络106连接至分布式网络系统100。例如，网络接口178可以包括有线接口(例如，以太网接口)和/或无线接口(例如，wi-fi、蓝牙、近场通信(nfc)或其他无线接口)。存储器180可以包括易失性或非易失性存储器、高速缓存或其他类型的存储器。块存储182可以包括闪式存储器、以或多个硬盘驱动器(hhd)或其他块存储设备。
计算设备108的处理器170执行操作系统(os)184和车队管理应用186，其被配置为生成穿梭路线信息并发送至车队中的穿梭车，生成一个或多个预订确认并发送至一个或多个用户设备，以及执行如下面更充分讨论的附加功能。块存储182可以存储一个或多个数据库188，其存储由车队管理应用186用于执行相应功能的数据结构。在一个示例中，计算设备108可以被用于控制包括为穿梭车队的一部分的一辆或多辆自动驾驶车辆。
现在参照图3，示出了用于管理穿梭车队314的系统300的另一示例。在一个示例中，系统的计算设备108可以被实现为执行上面关于图2所描述的车队管理应用186。类似地，计算设备108可以经由一个或多个网络(例如上面关于图1-图2所描述的网络106)以通信的方式连接至用户设备102、穿梭车队104和/或交通、天气和固定路线信息源316。根据一个示例，交通、天气和固定路线信息源316可以被实现为上面关于图1所描述的道路交通计算设备110、天气计算设备112和固定路线运输网络计算设备114。
计算设备108包括穿梭车分配模块304、预定确认模块306、缓冲生成模块308和通信模块310。计算设备108被配置为如下操作。
通信模块310，其在合适的逻辑控制下可以实现为收发器等，被配置为从一个或多个用户设备102中的一个用户设备获取(即，取得或接收)穿梭车预订请求318。穿梭车预订请求318可以包括目标目的地到达时间、上车地点和/或目的地位置。目标目的地到达时间可以描述特定时间(或者，根据一些示例，时间窗)，在该时间点处，放置请求318的一个或多个用户希望由车队104中的穿梭车在他们的目的地下车。上车地点可以描述放置请求318的一个或多个用户想要由车队104的穿梭车接载的位置，并且可以用文本地址、文本地理定位坐标(例如，gps坐标、纬度/经度坐标等)和/或视觉地理定位坐标(例如，如通过数字地图上的“上车地点”指示符表示)来表示。类似地，目的地位置可以描述放置请求318的一个或多个用户想要由车队104的穿梭车下客的位置，并且可以用文本地址、文本地理定位坐标(例如，gps坐标、纬度/经度坐标等)和/或视觉地理定位坐标(例如，如通过数字地图上的“下车地点”指示符表示)来表示。
通信模块310还可以被配置为从穿梭车队104的每辆穿梭车处获取穿梭车信息320。穿梭车信息320可以包括与穿梭车队104中的每辆穿梭车相关联的标识信息、位置信息、占用信息和/或座位配置信息。标识信息可以包括足以唯一地标识车队104中的每辆穿梭车的信息，例如但不限于vin号、车牌号、品牌和型号、颜色等。位置信息可以包括描述车队104中的每辆穿梭车当前位置的信息和/或描述车队104中的每个车辆当前前进的位置的当前路线信息。位置信息可以用文本地址、文本地理定位坐标(例如，gps坐标、纬度/经度坐标等)和/或视觉地理定位坐标(例如，通过数字地图上的“穿梭位置”指示符表示)来表示。占用信息可以包括描述车队104中的每辆穿梭车的当前或预计占用情况(例如，多少座位被占用和/或多少座位可用)的信息。例如，以及如下面更详细描述的，根据一些实施方式，系统300可以操作在共享乘坐模式，从而与单独的穿梭车预订请求相关联的多个乘客可以在他们的全部或部分旅程中共享穿梭车。座位配置信息可以包括描述车队104中的每辆车的可能的座位布置的信息。例如，座位配置信息可以指示给定穿梭车具有折叠座位，其可以折叠以在穿梭车车厢内提供附加空间。根据其他示例，座位配置信息可以指示给定穿梭车是否轮椅可上或是否包括儿童座椅。
另外，通信模块310可以被配置为从交通、天气和固定路线信息源316获取交通网络状态信息322。交通网络状态信息322可以包括与上面提供的那些类型的信息一致的交通信息、天气信息和/或固定路线运输状态信息。
穿梭车分配模块304被配置为从通信模块310获取穿梭车预订请求318、穿梭车信息320和运输网络状态信息322并且基于上述信息执行进一步处理。更具体地，根据一个示例，穿梭车分配模块304被配置为基于穿梭车预订请求318、穿梭车信息320(在一些示例中，包括座位配置信息)和运输网络状态信息322生成穿梭路线信息324。穿梭路线信息324包括指示车队104的穿梭车在上车地点接载一个或多个乘客(例如，与发布穿梭车预订请求318的用户设备相关联的一个或多个乘客)并且在目标目的地到达时间之前将乘客运输至目的地位置的指令。
根据一些示例，其中车队104中的一辆或多辆穿梭车包括自动驾驶车辆(例如，自动驾驶汽车)，穿梭路线信息324可以被配置为使自动驾驶车辆中的至少一辆在上车地点接载乘客并且在目标目的地到达时间之前将乘客运输至目的地位置。
根据另一示例，穿梭车分配模块304还被配置为从穿梭车队104中选择特定穿梭车以满足穿梭车预订请求318。该选择可以基于穿梭车预定请求318、穿梭车信息320和/或运输网络状态信息322。在一个实施方式中，穿梭车分配模块304可以在生成穿梭路线信息324之前从穿梭车队104中选择特定穿梭车，或者选择特定穿梭车作为生成穿梭路线信息324的一部分。以这种方式，穿梭车分配模块304可以将穿梭路线信息324引导至车队104中的合适的穿梭车。通信模块310可以被配置为遵循该选择将穿梭路线信息324发送至适当的穿梭车。
在一个实施方式中，穿梭车分配模块304被配置为动态地对穿梭车预订请求318、穿梭车信息320和/或运输网络状态信息322中的任意一个的改变作出反应，以保证最佳的穿梭车分配和路线。更具体地，穿梭车分配模块304可以被配置为基于穿梭车预订请求318、穿梭车信息320和/或运输网络状态信息322中的任意一个的改变生成更新后穿梭路线信息332。在这种实施方式下，通信模块310可以被配置为将更新后穿梭路线信息332发送至穿梭车。更新后穿梭路线信息332可以以某种方式修改先前发送的穿梭路线信息324，例如，通过指令穿梭车采取不同路线以接载和/或放下一个或多个乘客。
预订确认模块306被配置为从通信模块310获取穿梭车预订请求318、穿梭车信息320和运输网络状态信息322并且基于上述信息执行进一步处理。更具体地，根据一个示例，预订确认模块306被配置为基于穿梭车预订请求318、穿梭车信息320和运输网络状态信息322确定预计目的地到达时间330。预计目的地到达时间330可以指示给定用户何时可期望到达被指示为穿梭车预订请求318的一部分的目的地位置。在一个示例中，预计目的地到达时间330可以与目标目的地到达时间相同。然而，在其他示例中，预计目的地到达时间330可以与被指示为穿梭车预订请求318的一部分的目标目的地到达时间不同。
此外，预订确认模块被配置为生成至少包括预计目的地到达时间330的预订确认326。在其他示例中，预订确认326可以包括预计目的地到达时间330之外的附加信息。例如，在一个实施方式中，预订确认326可以包括所分配的穿梭车标识信息。所分配的穿梭车标识信息可以包括标识穿梭车队104中被分配以满足预订请求318的特定穿梭车的信息。根据另一示例，预订确认326可以包括上车地点确认信息。上车地点确认信息可以包括上车地点的文本和视觉表示。预定确认326的各种实施方式参照图5更进一步详细例示和描述。
在一个实施方式中，预订确认模块306被配置动态地对对穿梭车预订请求318、穿梭车信息320和/或运输网络状态信息322中的任意一个的改变作出反应，以使用户及时了解可能影响(例如，预计目的地到达时间330)的情况。更具体地，预订确认模块306可以被配置为基于穿梭车预订请求318、穿梭车信息320和/或运输网络状态信息322中的任意一个的改变来确定更新后预计目的地到达时间338。此外，预订确认模块306被配置为生成包括更新后预计目的地到达时间338的更新后预订确认334。在这种实施方式下，通信模块310可以被配置为将更新后预订确认334发送至用户设备102。更新后预定确认334可以以某种方式修改先前发送的预订确认326，例如，通过指示更新后预计目的地到达时间338。
缓冲生成模块308被配置为从穿梭车分配模块304获取穿梭路线信息324，以及从通信模块310获取运输网络状态信息322，并且基于上述信息执行进一步处理。更具体地，根据一个示例，缓冲生成模块308被配置为基于穿梭路线信息324和运输网络状态信息322生成缓冲时间328。缓冲时间328被设计为基于穿梭路线信息324和运输网络状态信息322预计与行程相关联的可能延迟。
根据一个或多个穿梭车在不同站点之间的固定路线运行的示例，缓冲生成模块308可以被配置成为一个或多个站点中的每一个生成相应缓冲时间328。缓冲时间328可以使用在本文所述的系统300中用于多种目的，包括但不限于：(i)设置用户(例如，顾客/骑行者)的期望；(ii)允许用于重新寻路至其他站点(例如，在固定路线模型中)的时间以提高系统效率(其中重新寻路事件可能消耗全部或部分缓冲)；和/或(iii)考虑“吞噬”缓冲的交通或其他意外延迟。根据一些示例，缓冲生成模块308可以基于典型的预期行程时间(例如，在基于与行程时间相关联的历史数据的固定路线系统中从第一站点到第二站点的预期行程时间)使用对数函数来生成缓冲时间328。
根据一个示例，预订确认模块306被配置为基于缓冲时间328确定预计目的地到达时间330。例如，不考虑缓冲时间328的情况下，预订确认模块306可能确定预计目的地到达时间330为下午7:00。然而，在考虑缓冲时间328的情况下，预订确认模块306可能确定预计目的地到达时间330为下午7:05。通过考虑行程中潜在的延迟，缓冲生成模块308可通过呈现可实现的预计目的地到达时间330增强用户体验。此外，尽管前述示例描述了基于缓冲时间328确定有限的预计目的地到达时间330，但是根据一些示例(以及下面参照图6更详细描述的)，预计目的地到达时间330可以包括诸如“预期到达时间”和“最大到达时间”的范围。
在一个实施方式中，缓冲生成模块308被配置为动态地对穿梭路线信息324和/或运输网络状态信息322中任意一个的改变作出反应，以提升任意预计目的地到达时间330的准确性。更具体地，缓冲生成模块308可以被配置为基于穿梭路线信息324和/或运输网络状态信息322中的至少一个的改变生成更新后缓冲时间336。根据该实施方式，预订确认模块306还可以被配置为基于更新后缓冲时间336确定更新后预计目的地到达时间338。此外，预订确认模块306可以被配置为生成包括更新后预计目的地到达时间338的更新后预订确认334。通信模块310可以被配置为将更新后预订确认334发送至用户设备102。
现在转向图4，示出了包括被配置为便于放置用户的穿梭车预订请求的图形用户界面(gui)402的用户设备400的一个示例。用户设备400可以包括任意合适的电子设备，例如上面关于用户设备102所描述的电子设备类型。gui402可以经由领域中已知的任意适合的机制接收输入，包括但不限于，经由触摸屏界面、触控笔、键盘、鼠标等或上述任意组合。gui402被配置为输出显示信息以及从用户获取输入。以这种方式，用户可以利用gui402以配置穿梭车预订请求的参数以及发布穿梭车预订请求。
gui402包括若干可配置参数。例如，gui402包括目标目的地到达时间字段404。该字段404允许用户输入他们希望到达其目的地的的特定时间。另外，gui402包括文本目的地位置输入字段406a和/或基于地图的目的地位置输入字段406b。用户可以经由文本目的地位置输入字段406a以文本方式输入目的地位置(例如，作为地址、交叉点、地标、经由地理位置坐标等)。另外或另选地，用户可以通过在数字地图上选择一个点经由基于地图的目的地位置输入字段406b来标识目的地位置。可以使用领域内已知的选择技术通过使用触摸屏界面、触控笔、键盘、鼠标等或上述的任意组合来进行选择。
gui402还包括文本上车地点输入字段408a和/或基于地图的上车地点输入字段408b。用户可以经由文本上车地点输入字段408a以文本方式输入上车地点(例如，作为地址、交叉点、地标、经由地理位置坐标等)。另外或另选地，用户可以通过在数字地图上选择一个点经由基于地图的上车地点输入字段408b来标识上车地点。可以使用领域内已知的选择技术通过使用触摸屏界面、触控笔、键盘、鼠标等或上述的任意组合来进行选择。基于地图的上车地点输入字段408b还示出了上面描述的多个其他特征。例如，基于地图的上车地点输入字段408b示出了含有上车地点的地理区域414。如上所述，根据一些实施方式，本文描述的系统(例如，如通过计算设备108实现的)可以基于与含有上车地点(并且，在一些示例中，另外或另选地含有目的地位置)的地理区域414相关联的天气状况、交通状况和/或固定路线运输状态信息来执行穿梭车选择和/或路线分配。
此外，基于地图的上车地点输入字段408b以火车轨道416的形式示出了固定路线运输网络的一个示例。根据一个示例，穿梭车系统可以知道沿着火车轨道416行驶的火车的状态，并且可以修改诸如穿梭车选择和/或路线分配的特征，以满足穿梭车预订请求。例如，本文描述的穿梭车管理系统可以选择第一穿梭车而非第二穿梭车以满足预订请求，尽管第二穿梭车距离上更靠近上车地点。这可能是因为，例如，穿梭车管理系统知道第二穿梭车必须停下来以允许火车在其通往上车地点的途中通过，使得第二穿梭车将比第一穿梭车花费更长时间以到达上车地点，尽管其距离上比第一穿梭车更靠近上车地点。类似地，本文描述的穿梭车管理系统可以利用固定路线运输系统的知识来为穿梭车分配特定路线。例如，返回至火车示例，穿梭车管理系统可以被配置为分配路线(例如，至上车地点或目的地位置)，该路线不一定是从起始点至终点的最短距离。但是这是最快的路线，因为它避免了需要停下来允许火车通过这样的事情。
gui402的乘客数量输入字段410允许用户标识将从上车地点行驶至目的地位置的乘客的数量。系统可以利用该信息，例如用于穿梭车选择和/或路线分配。关于穿梭车选择，系统可以使用“乘客数量”信息以确保所分配的穿梭车具有足够占用率。给定穿梭车的占用率可以基于，例如，给定穿梭车的当前乘客数量(例如，通过位于穿梭车内的合适的占用率传感器来确定)和/或座位配置信息来确定，所述座位配置信息可指示穿梭车的座位布置可以重配置(例如，通过放下折叠、移动、增加或移除座位)以容纳附加乘客。
gui402的需要轮椅通道输入字段412允许用户指示是否有任意乘客需要轮椅通道。系统可利用该信息，例如用于穿梭车选择，以确保所分配的穿梭车是轮椅可上车的。
gui402的儿童乘客数量输入字段418允许用户指示是否有任意儿童将被包括为乘客。系统可以利用该信息，例如用于穿梭车选择。例如，如果将有儿童乘坐，则选择包括儿童安全座椅等的穿梭车是重要的。类似地，可以利用关于儿童是否将成为乘客的知识来评估占用率，因为儿童通常比成人占用更少的空间。
最后，发布穿梭车请求按钮420允许用户完成他们的穿梭车预订请求。一旦用户选择发布穿梭车请求按钮420(使用领域中已知的任意选择技术)，穿梭车预订请求(随着其关联参数一起)将从用户设备400发送至本文描述的穿梭车管理系统(例如，通过计算设备108所实现的)。
现在转向图5，示出了包括被配置为确认用户的穿梭车预订请求的图形用户界面(gui)502的用户设备400的另一个示例。gui502可以经由领域中已知的任意适合的机制接收输入，包括但不限于，经由触摸屏界面、触控笔、键盘、鼠标等或上述任意组合。gui502被配置为输出显示信息以及，在一些示例中，从用户获取输入。以这种方式，用户可以利用gui502来查看他们的穿梭车预订的准确性和/或取消或修改先前放置的穿梭车预订请求。
gui502包括预计目的地到达时间字段504。注意，虽然目标目的地到达时间被设为est时间下午7:00(参见图4的目标目的地到达时间输入字段404)，但是预计目的地到达时间被设为est时间7:05。这是因为，在这个示例中，系统确定的预计到达时间(根据上述进行这种确定的过程)与用户的目标目的地到达时间不同。尽管图5示出的示例示出了预计目的地到达时间晚于目标目的地到达时间，但是在一些示例中，目标目的地到达时间和预计目的地到达时间可以相同，或者预计目的地到达时间可以早于目标目的地到达时间。另外，如上所述，在一些示例中，预计目的地到达时间可以至少部分地基于缓冲时间。预计目的地到达时间字段504通常用户不可配置。
gui502的目的地位置字段506a以文本方式指示与穿梭车预订请求相关联的目的地位置，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的文本目的地位置输入字段406a中的目的地位置中的错误)。类似地，基于地图的目的地位置字段506b可视地指示与穿梭车预订请求相关联的目的地位置，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的基于地图的目的地位置输入字段406b中的目的地位置中的错误)。
gui502的上车地点字段508a以文本方式指示与穿梭车预订请求相关联的上车地点，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的文本上车地点输入字段408a中的上车地点中的错误)。类似地，基于地图的上车地点字段508b可视地指示与穿梭车预订请求相关联的上车地点，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的基于地图的上车地点输入字段408b中的上车地点中的错误)。另外，基于地图的上车地点字段508b示出了含有上车地点的地理区域414和参照图4所描述的火车轨迹416。
gui502的乘客数量字段510标识被确认用于穿梭车预订请求的乘客数量，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的输入字段410中的乘客数量的错误)。
gui502的需要轮椅通道字段512标识被分配以满足预订请求的穿梭车是否轮椅可进入，并且根据一些实施方式，可以由用户编辑(例如，以更正图4的需要轮椅通道输入字段412的错误)。
gui502的儿童乘客数量字段518标识被确认用于穿梭车预订请求的儿童乘客数量，并且根据一些实施方式，可以由用户编辑(例如，以更正输入至图4的输入字段418中的儿童乘客数量的错误)。
分配的穿梭车id字段520提供了与所分配的穿梭车相关联的标识信息。该信息可以包括但不限于vin号、车牌号、品牌和型号、颜色等。分配的穿梭车id字段520通常用户不可配置。
最后，取消穿梭车请求按钮522允许用户取消他们的穿梭车预订请求。一旦用户选择取消穿梭车请求按钮522(使用领域中已知的任意选择技术)，取消信息可以从用户设备400发送至本文描述的穿梭车管理系统(例如，通过计算设备108所实现的)。
现在参照图6，示出了例示了用于管理跨越固定路线运输网络的多个穿梭车预订请求的过程示例的状态图600和附表602、604。状态图600示出了由穿梭车采取的穿过作为固定路线运输网络的一部分的站点a至f的示例性路线。预订请求表602示出了预订请求的顺序(从上至下)、针对每个预订请求的所请求的上车点(左栏)和所请求的下车点(右栏)。穿梭车1路线表604示出了基于预订请求的针对网络中每个站点(最左栏)的预期到达时间(中间栏)和最大到达时间(最右栏)。
所做出的预订的时间顺序显示在预订请求表602中(最高请求为时间上最先而最低请求为时间上最后)。注意，第一请求是从a至c，而第二请求是从a至b。这提出了一个问题，为什么路线不是从a至c到a至b？这是因为，根据该示例，系统(例如，由计算设备108实现)识别共同的“a”站点，检查穿梭车的容量，并决定将它们组合。然而，这提出了一个额外的问题，即为什么路线不是从a至c至b，既然a到c的请求是先做出的？这是因为，根据该示例，系统计算出b处于a和c之间，因此从a行驶至b至c更高效。上述调度表可能会提出一个问题，即它是否会延迟a至c的预订，因为该行程将因前往b站点而中断。然而，a至c的预订不会被认为迟到，因为产生了缓冲时间来解释这种延迟，因此从乘客的角度来看，行程是准时的。
以下反映了根据图6的状态图600和表602、604的穿梭路线的概要。建立从站点a至站点c的第一预订，穿梭路线是从站点a至站点c，在站点c设置额外4分钟的缓冲时间。穿梭车从站点a出发的时间为5:00，到达站点c的时间为5:05(缓冲最大到达时间5:09)。
建立从a至b的第二预订，系统使用站点c的缓冲重新为穿梭车寻路，并决定行进至站点b然后至站点c，在站点b设置3分钟的缓冲(针对这条路线我们已使用了2分钟的站点c缓冲)。新的穿梭路线为站点a5:00，站点b5:05(缓冲5:07)，站点c5:07(缓冲5:09)。
建立从b至d的第三预订，系统决定将停靠点增加至路线终点，并在站点d设置3分钟的缓冲。新的穿梭路线为站点a5:00，站点b5:04(缓冲5:07)，站点c5:07(缓冲5:09)，以及站点d5:11(缓冲5:14)。
建立从c至f的第四预订，系统决定为穿梭车重新寻路并在站点c和站点d之间增加停靠点f(使用1分钟的站点d缓冲)，在站点f设置3分钟的缓冲。新的穿梭路线为站点a5:00，站点b5:04(缓冲5:07)，站点c5:07(缓冲5:09)，站点f5:10(缓冲5:13)，以及站点d5:12(缓冲5:14)。
建立从e至f的第五预订，系统决定为穿梭车重新寻路并在站点c和站点f之间增加停靠点e(使用1分钟的站点f缓冲和1分钟的站点d缓冲)，并在站点e设置2分钟的缓冲。新的穿梭路线为站点a5:00，站点b5:04(缓冲5:07)，站点c5:07(缓冲5:09)，站点e5:09(缓冲5:11)，站点f5:11(缓冲5:13)，以及站点d5:13(缓冲5:14)。
最终，建立从c至d的最后一个预订，系统决定优选方案为使用当前路线，因为站点c和站点d已经是路线的一部分，站点c的出发时间5:07和到达站点d的时间5:13，路线不改变，并且任意车站的缓冲也不改变。
现在参照图7，提供了示出用于管理穿梭车队的方法700的流程图。方法700在702处开始，在该处从用户设备获取穿梭车预订请求。穿梭车预订请求可以包括目标目的地到达时间、上车地点和目的地位置中的至少一个。在704处，从穿梭车队中的每辆穿梭车获取穿梭车信息。穿梭车信息可以包括与穿梭车队中的每辆穿梭车相关联的标识信息、位置信息和占用信息。在706处，获取运输网络状态信息。运输网络状态信息可以包括与含有上车地点的地理区域相关联的交通信息和天气信息。
在708处，可以基于穿梭车预订请求、穿梭车信息和运输网络状态信息生成穿梭路线信息。穿梭路线信息可以包括指示穿梭车在上车地点接载乘客并在目标目的地到达时间之前将该乘客运输至目的地位置的指令。在710处，基于穿梭车预订请求、穿梭车信息和运输网络状态信息确定预计目的地到达时间。在712处，生成预订确认。预定确认可以包括预计目的地到达时间。在714处，将穿梭路线信息发送至穿梭车。在716处，将预订确认发送至用户设备。在716之后，方法700结束。
除了其他特征之外，本文所描述的系统和方法可以提供以下能力。一种车队管理系统(例如，通过计算设备108实现)，其具有针对每个预订请求(以及对于每个其他系统“事件”)的整个运输网络的完全知识。由于对运输网络的全面了解，可以通过为客户或运输系统选择优选(例如，最佳)方案来优化预订请求(或其他事件，例如延迟)(不论优选被定义为最快还是最有效)。
此外，系统中的每个事件(即，从a点到b点的行程、穿梭车停下来以下客等)具有预计目的地到达时间，但也可以包括缓冲时间，其可以基于事件类型、运输网络的状态和其他因素来动态计算。缓冲时间可以用于，例如穿梭车寻路，向用户提供可实现的预计到达时间以提升用户满意度等。
另外，本发明的系统和方法支持可按片区或按预订调整的效率比。例如，系统允许片区(例如，底特律市)调整其运输网络期望的效率。滑动比例是“先来先服务”客户满意度与“功利性”(高效)方法之间的选择。这种选择可以以每次行程为基础一路延伸到客户：您想要支付5美元，但可能需要20分钟才能到达目的地，或者您想要支付20美元以在10分钟内到达目的地？
此外，本系统和方法基于系统事件提供运输网络负载的动态重新寻路和重新平衡。当运输网络中引入了新容量时，本系统可以将待处理(即将到来的)的预订的负载重新平衡到新容量上。当运输车辆运行“延迟”超过特定阈值时，系统可以检查运输网络的其余部分以查看对于即将到来的预订是否有更好的选择。当系统繁忙且用户对于行程的选择变得无效时(例如，穿梭车预订请求不能满足)，系统可以尝试在先前选择的特定时间范围内寻找下一个最佳选择行程。
本系统和方法还提供固定路线时间表的知识(系统的内部和外部)。也就是说，本系统和方法提供固定路线系统(其按循环或固定时间表运行)与动态运输网络之间的集成，将调度时间与动态上车和下车匹配。当先前的支路被取消或延迟时，可以提供对行程的未来“支路(leg)”的自动调整。向用户呈现的选择可以包括来自每种类型系统的聚合/组合的最佳可能选项。此外，本系统可以被配置为出租车服务或乘车共享服务。
根据一些示例，本系统可以基于用户有多“匆忙”来实现定价模型(例如，如果用户使网络劣化则支付更多费用)。由本系统实现的定价模型可以非常灵活。例如，可以基于以下变量中的一个或多个对预订进行定价：行驶距离、乘车时间、乘坐者类型、乘车优先级、固定费率、多区域费率、网络去优化成本、运输网络供应/需求等。例如，乘坐者可以为更长的行程支付更少的金额。“分层”定价模型概念也可以作为本系统的一部分。
此外，本系统和方法利用关于动态车辆容量的知识(例如，穿梭车是否包括可互换座椅类型、儿童座椅、轮椅等)。这允许本系统针对每个预订区分特定容量要求，以及将这些要求与具有该容量能力的车辆相匹配。车辆可具有固定的容量和/或动态容量(即，两个常规座椅被折叠以为轮椅腾出空间)。
根据一些实施方式，本系统和方法可以针对到达时间而不是出发时间来优化穿梭调度和路线。例如，本系统可以允许用户指定他们所需的出发时间或他们所需的到达时间。该系统还可以允许在未来同一天内进行多次预订。
本系统和方法还可以提供用户上下穿梭车的检测。例如，根据一些实施方式，穿梭车内可以装配传感器(例如，布置在座椅内的气囊传感器)以检测在一个或多个座椅区域(例如，座位、用于轮椅的区域等)内的一个或多个乘客的存在。以这种方式，系统可以允许关于车队中每辆穿梭车的实时占用信息以及“未出现”的检测。
如上所提到的，本系统可以被配置成与自动驾驶车辆(在其穿梭时)结合使用。穿梭车可以在系统的指令下行动以遵循预定路线并进行预定的停靠。
在一些示例中，系统可以是多模式的，因为它可以允许组合不同运输网络中的一个或多个预订以创建行程，当事件导致系统中的班次或优先级改变时自动调整每个预订。
在一些实施方式中，例如，在系统按照具有预先指定的上车和下车地点的固定路线系统运行的情况下，系统可以向用户提供指令以到达相关的上车或下车地点。例如，指令可以指示如何到达行程的节点/支路之间，如何到达第一个上车节点，如何到达移动节点(或者一开始不确定但随时间变得更加确定的节点位置)等。
根据一些实施方式，系统可以与各种区域和枢纽一起运行。例如，片区可以划分为区域，区域是站点的逻辑分组。这些区域可以分离穿梭操作，并提供允许节点之间传输的枢纽。利用片区至片区的枢纽还可进行片区之间的传输。区域和片区还可以具有物理边界，其可以用来提供自动管理警告、其他约束，以及具有服务等级和定价模型的含义。
在一些示例中，系统可以提供对紧急事件的自动、系统化响应。例如，系统能够以各种方式响应紧急情况。由于完整的系统知识，可以通知管理员/司机/用户，可以取消预订，并且可以自动地将穿梭车从“故障”位置(范围、区域、站点等)转移。
最后，本文描述的本系统和方法可以提供预测能力。交通可能因日期、时间、假期、天气、地理位置、交通媒介和其他一些因素而变化。本系统可以基于该数据更准确地为预订预测估计到达时间(eta)。可以获取关于供应和需求以及驾驶员和骑车者行为的附加数据，以进一步细化eta时间。还可以基于诸如预订需求和/或一天中的时间之类的标准来预测穿梭车位置。
前面的描述本质上仅是说明性的，绝不是要限制本发明、其应用或用途。本发明的广泛教导可以以各种形式实现。因此，尽管本发明包括特定示例，但是本发明的真实范围不应受此限制，因为在研究了附图、说明书和所附权利要求之后，其他修改将变得显而易见。应当理解，方法内的一个或多个步骤可以按不同的顺序(或同时)执行，而不改变本发明的原理。此外，尽管上面将每个实施例描述为具有特定特征，但是关于本发明的任何实施例描述的那些特征中的任何一个或多个可以在任何其他实施例的特征中实现和/或与其组合，即使没有明确描述该组合。换句话说，所描述的实施例不是相互排斥的，并且一个或多个实施例彼此的排列仍然在本发明的范围内。
元件之间的空间和功能关系(例如，模块、电路元件、半导体层等之间)使用各种术语来描述，包括“连接”、“接合”、“耦合”、“相邻”、“旁边”、“在......顶部”、“在......之上”、“在......之下”以及“布置于”。除非明确地描述为“直接”，否则当在上面的公开内容中描述第一元件与第二元件之间的关系时，该关系可以是直接的关系，其中在第一元件和第二元件之间不存在其他中间元件，但也可以是间接关系，其中在第一元件和第二元件之间存在(空间或功能上)一个或多个中间元件。如这里所使用的，短语a、b和c中的至少一个应该被解释为使用非排他性逻辑or表示逻辑(aorborc)，并且不应该被解释为表示“至少一个a、至少一个b中以及至少一个c。“
在图中，箭头所示的箭头方向通常表示图示中感兴趣的信息流(例如数据或指令)。例如，当元件a和元件b交换各种信息但是从元件a发送到元件b的信息与图示相关时，箭头可以从元件a指向元件b。该单向箭头并不意味着没有其他信息从元件b发送到元件a。此外，对于从元件a发送到元件b的信息，元件b可以向元件a发送对信息的请求或接收确认。
在本申请中，包括下面的定义，术语“模块”或术语“控制器”可以用术语“电路”代替。术语“模块”可以指代、作为部分或包括：专用集成电路(asic)；数字、模拟或混合模拟/数字离散电路；数字、模拟或混合模拟/数字集成电路；组合逻辑电路；现场可编程门阵列(fpga)；执行代码的处理器电路(共享、专用或组)；存储由处理器电路执行的代码的存储器电路(共享、专用或组)；提供所述功能的其他适合的硬件组件；或者上述部分或全部的组合，例如在片上系统中。
该模块可以包括一个或多个接口电路。在一些示例中，接口电路可以包括连接至局域网(lan)、因特网、广域网(wan)或其组合的有线或无线接口。本发明的任意给定模块的功能可以分布在经由接口电路连接的多个模块之间。例如，多个模块可以允许负载平衡。在另一个示例中，服务器(也称为远端或云)模块可以代表客户端模块完成一些功能。
如上所使用的术语代码可以包括软件、固件和/或微代码，并且可以指代程序、例程、函数、类、数据结构和/或对象。术语共享处理器电路包含执行来自多个模块的一些或所有代码的单个处理器电路。术语组处理器电路包括处理器电路，该处理器电路与附加处理器电路组合，执行来自一个或多个模块的一些或所有代码。对多个处理器电路的参考包括分立管芯上的多个处理器电路、单个管芯上的多个处理器电路、单个处理器电路的多个核、单个处理器电路的多个线程，或上述的组合。术语共享存储器电路包含存储来自多个模块的一些或所有代码的单个存储器电路。术语组存储器电路包括与附加处理器组合，存储来自一个或多个模块的一些或所有代码的处理器电路。
术语存储器电路是术语计算机可读介质的子集。如这里使用的术语计算机可读介质不包含通过介质(例如在载波上)传播的瞬时电信号或电磁信号；因此，术语计算机可读介质可以被认为是有形的和非暂时性的。非暂时性有形计算机可读介质的非限制性示例是非易失性存储器电路(例如闪存电路、可擦除可编程只读存储器电路或掩膜只读存储器电路)、易失性存储器电路(例如静态随机存取存储器电路或动态随机存取存储器电路)、磁存储介质(例如模拟或数字磁带或硬盘驱动器)和光存储介质(例如cd、dvd或蓝光光盘)。
本申请中描述的装置和方法可以部分或全部由专用计算机实现，该专用计算机通过配置通用计算机以执行计算机程序中包含的一个或多个特定功能而创建。上述功能块、流程图组件和其他元件用作软件规范，其可以通过熟练技术人员或程序员的例行工作转换成计算机程序。
计算机程序包括存储在至少一个非暂时性有形计算机可读介质上的处理器可执行指令。计算机程序还可以包括或依赖于存储的数据。计算机程序可以包括与专用计算机的硬件交互的基本输入/输出系统(bios)、与专用计算机的特定设备交互的设备驱动程序、一个或多个操作系统、用户应用程序、后台服务、后台应用程序等。
计算机程序可以包括：(i)要解析的描述性文本，例如html(超文本标记语言)、xml(可扩展标记语言)或json(javascript对象表示法)，(ii)汇编代码，(iii)由编译器从源代码生成的目标代码，(iv)由解释器执行的源代码，(v)由即时编译器编译和执行的源代码等。仅作为示例，源代码可以使用来自c、c++、c#、objectivec、swift、haskell、go、sql、r、lisp、
权利要求中所述的任何元件均不旨在是35u.s.c§112(f)含义内的装置加功能元件，除非使用短语“用于......的装置”明确地叙述了元件，或者在方法权利要求的情况下使用短语“用于……的操作”或“用于……的步骤”。
- 还没有人留言评论。精彩留言会获得点赞！