CN116188098A - 约车订单处理方法、装置及设备 - Google Patents

Abstract

本申请公开了一种约车订单处理方法、装置及设备，此方法应用于车辆，车辆上设置有第一显示屏和第二显示屏，该方法包括：获取第一约车订单和当前车辆位置，第一约车订单包括起始地和目的地；在第一显示屏显示第一约车订单的订单信息，并在第二显示屏上显示第一约车订单的目标界面，目标界面包括预设控件，预设控件用于使用户确认第一约车订单；在当前车辆位置与起始地不一致时，驱动车辆行驶至起始地；接收用户对预设控件的确认操作；响应于确认操作，驱动车辆从起始地驶向目的地。本申请处理第一约车订单的过程中，无需司机接收订单并操作车辆。

Description

约车订单处理方法、装置及设备

技术领域

本申请属于无人驾驶车辆技术领域，尤其涉及一种约车订单处理方法、装置及设备。

背景技术

随着城市的发展，打车需求已经是社会各个阶层人士的普遍需求。近年来，出现了各种网约车软件，为司机和用户提供了一个便利的工具，解决了出租车司机和用户之间的信息不对称问题。

然而，现有的约车订单处理方案中，需要借助司机的交互才能完成约车订单处理，车辆无法自动完成约车订单的处理。

发明内容

本申请实施例提供一种约车订单处理方法、装置及设备，能够使车辆自动完成约车订单的处理。

根据本申请的第一个方面，本申请实施例提供一种约车订单处理方法，此方法应用于车辆，车辆上设置有第一显示屏和第二显示屏，该方法包括：

获取第一约车订单和当前车辆位置，第一约车订单包括起始地和目的地；

在第一显示屏显示第一约车订单的订单信息，并在第二显示屏上显示第一约车订单的目标界面，目标界面包括预设控件，预设控件用于使用户确认第一约车订单；

在当前车辆位置与起始地不一致时，驱动车辆行驶至起始地；

接收用户对预设控件的确认操作；

响应于确认操作，驱动车辆从起始地驶向目的地。

可选地，驱动车辆从起始地驶向目的地，包括：

获取车辆的实时位置信息以及从实时位置信息到目的地的路况信息；

根据路况信息，规划从实时位置信息到目的地的路径，得到目标路径；

根据目标路径驱动车辆从起始地驶向目的地。

可选地，方法还包括：

在车辆到达目的地之后，生成第一约车订单的第一计费信息；

在目标终端显示第一计费信息，以使用户根据第一计费信息支付费用，目标终端包括第二显示屏或用户的移动终端。

可选地，第一计费信息包括总费用信息和目标单项费用，目标单项费用包括长途费、等待费以及跨城费中的至少一项。

可选地，在目标终端显示第一计费信息之后，方法还包括：

接收第一约车订单的订单计费异常请求；

对订单计费异常请求进行异常判定，生成异常判定结果；

将判定结果发送至目标终端。

可选地，方法还包括：

接收针对第一约车订单的未上车申诉信息；

获取用户对预设控件的确认操作时车辆的第一位置；

比较起始地和第一位置之间的距离是否超过预设距离；

在确定起始地和第一位置之间的距离不超过预设距离情况下，向用户的移动终端发送第一信息，第一信息用于提示用户未上车申诉信息申诉未成功；

在确定起始地和第一位置之间的距离超过预设距离且第一约车订单的费用已支付的情况下，向收费端发送第二信息，第二信息用于通知收费端将已收取的第一约车订单的费用退还给用户；

在确定起始地和第一位置之间的距离超过预设距离且第一约车订单的费用未支付的情况下，向用户的移动终端发送第三信息，第三信息用于提示第一约车订单免单。

可选地，方法还包括：

获取第二订单的取消时长，取消时长为第二订单的生成时刻到取消时刻之间的时长；

在持续时长大于预设时长的情况下，获取网约车抵达第二订单的起始地的第一时刻；

根据第一时刻，确定车辆是否迟到；

在确定车辆迟到的情况下，判定车辆需要承担第二订单取消的责任，用户无需承担第二订单取消的责任；

在确定车辆未迟到的情况下，判定车辆无需承担第二订单取消的责任，用户需要承担第二订单取消的责任。

可选地，在订单状态为取消的情况下，获取第二订单信息的取消时长之前，方法还包括：

获取车辆的实时位置信息；

根据实时位置信息判断车辆是否抵达第二订单的起始地；

若车辆抵达第二订单的起始地，则向用户的移动终端发送第四信息，第四信息用于提示用户车辆已经抵达起始地。

根据本申请的第二个方面，本申请实施例提供一种车辆，其包括：

获取模块，用于获取第一约车订单和当前车辆位置，第一约车订单包括起始地和目的地；

第一显示模块，用于在第一显示屏显示第一约车订单的订单信息，并在第二显示屏上显示第一约车订单的目标界面，目标界面包括预设控件，预设控件用于使用户确认第一约车订单；

第一驱动模块，用于在当前车辆位置与起始地不一致时，驱动车辆行驶至起始地；

接收模块，用于接收用户对预设控件的确认操作；

第二驱动模块，用于响应于确认操作，驱动车辆从起始地驶向目的地。

根据本申请的第三个方面，本申请实施例提供一种订单处理设备，该设备包括：处理器以及存储有计算机程序指令的存储器；

处理器执行计算机程序指令时实现第一个方面中的约车订单处理方法。

本申请实施例的约车订单处理方法、装置及设备，通过车辆在接收第一约车订单后，自动操作车辆驶向起始地等候乘客；并在乘客上车后，主动将订单信息显示给乘客，只有待乘客确认了订单信息后，才驱动车辆将乘客由起始地送至目的地，整个处理第一约车订单的过程中，无需司机接收订单并操作车辆，实现了车辆的自动化运行；此外，本方法可以适用于无人驾驶车辆，有利于实现车辆的自动化运行。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据一示例性实施例示出的一种约车订单处理方法的一流程示意图；

图2是根据一示例性实施例示出的一种约车订单处理方法的另一流程示意图；

图3是根据一示例性实施例示出的一种约车订单处理方法的再一流程示意图；

图4是根据一示例性实施例示出的一种约车订单处理方法的再一流程示意图；

图5是根据一示例性实施例示出的一种约车订单处理方法的再一流程示意图；

图6是根据一示例性实施例示出的一种车辆控制模块的结构框图；

图7是根据一示例性实施例示出的一种约车订单处理设备的结构框图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非他性地包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

如背景技术部分所述，现有技术中，由于执行约车订单中，需要借助司机的交互才能完成约车订单处理，而司机本身存在主观因素，因此导致司机在执行约车订单的过程中，将存在很多问题。

基于此，本申请实施例提供的约车订单处理方法中，通过车辆在接收第一约车订单后，自动操作车辆驶向起始地等候乘客；并在乘客上车后，主动将订单信息显示给乘客，只有待乘客确认了订单信息后，才驱动车辆将乘客由起始地送至目的地，整个处理第一约车订单的过程中，无需司机接收订单并操作车辆，实现了车辆的自动化运行；此外，本方法可以适用于无人驾驶车辆，有利于实现车辆的自动化运行。

基于此，本申请提供了一种约车订单处理方法、装置及设备。下面首先对本申请实施例所提供的约车订单处理方法进行介绍。

图1示出了本申请一个实施例提供的约车订单处理方法的一流程示意图。如图1所示，该方法应用于车辆，车辆上设置有第一显示屏和第二显示屏，该方法可以包括以下步骤：

S101，获取第一约车订单和当前车辆位置，第一约车订单包括起始地和目的地；

S102，在第一显示屏显示第一约车订单的订单信息，并在第二显示屏上显示第一约车订单的目标界面，目标界面包括预设控件，预设控件用于使用户确认第一约车订单；

S103，在当前车辆位置与起始地不一致时，驱动车辆行驶至起始地；

S104，接收用户对预设控件的确认操作；

S105，响应于确认操作，驱动车辆从起始地驶向目的地。

基于上述实施例，通过车辆在接收第一约车订单后，自动操作车辆驶向起始地等候乘客；并在乘客上车后，主动将订单信息显示给乘客，只有待乘客确认了订单信息后，才将乘客由起始地送至目的地，整个处理第一约车订单的过程中，无需司机接收订单并操作车辆，实现了车辆的自动化运行；此外，本方法可以适用于无人驾驶车辆，有利于实现车辆的自动化运行。

在S101中，安全员通过操作位于车辆上的第一显示屏，给车辆开启接单模式，使得车辆可以接收订单；当用户通过手机发起第一约车订单后，车辆便可以接收第一约车订单，并且通过车辆自身的定位系统，获取车辆接收第一约车订单时的当前车辆位置；可以理解地，第一约车订单包括起始地和目的地，用户需要从起始地驶向目的地。

在S102中，第一显示屏将给安全员显示第一约车订单的订单信息，并且第二显示屏也将给用户显示第一约车订单的订单信息，用户可以根据第二显示屏上的订单信息，查看订单信息是否与自己所需的行程是否相符合，如果相符则用户可以通过点击第二显示屏上的预设控件，对第一约车订单的订单信息进行确认。

作为示例，订单信息包括起始地、目的地、起始地至目的地的预设路径、预估用时等。

在S103中，当当前车辆位置和起始地的位置不一致时，车辆的驱动模块将驱动车辆行驶至起始地去接用户上车。

在S104中，在用户上车后，通过点击位于第二显示屏上的预设控件，执行确认操作，确认第一约车订单的订单信息无误。

在S105中，在用户确认完订单信息后，车辆的驱动模块将驱动车辆由起始地驶向目的地。

为了能有效地减少车辆行驶到目的地的时间，本申请还提供了约车订单处理方法的另一种实现方式。

如图2示出了本申请一个实施例提供的约车订单处理方法的另一流程示意图，如图2所示，在上述S105中，可以包括：

S201，获取车辆的实时位置信息以及从实时位置信息到目的地的路况信息；

S202，根据路况信息，规划从实时位置信息到目的地的路径，得到目标路径；

S203，根据目标路径驱动车辆从起始地驶向目的地。

基于上述实施例，通过根据车辆的实时位置信息以及到目的地的路况信息，根据路况信息实施调整规划到目的地的路径，从而使得车辆可以时刻走在最优选的路径上，减少了车辆行驶到目的地的时间，使得车辆可以快速地将用户送至目的地。

在S201中，车辆上的定位系统对车辆定位，并通过定位系统获取车辆的实时位置信息，更具体地，车辆设置有高精地图，高精地图不仅能够给车辆提供定位，还可以通过高精地图将驶向目的地路途中的路况信息反馈给车辆。

在S202中，根据车辆的实时位置以及路况信息，给出驶向目的地的最优目标路径；

作为示例，最优目标路径可以是用时最短的目标路径、路程最短目标路径等。

在S203中，目标路径将在第二显示屏中显示，若目标路径和用户确认的订单信息中的预估路径存在差异，及目标路径对预估路径进行了调整，则需要用户重新对预设控件执行确认操作后，车辆才会按照目标路径行驶至目的地，否则则将依旧按照预设路径行驶。

为了能更准确地将计费信息告知用户，本申请还提供了约车订单处理方法的另一种实现方式。

如图3示出了本申请一个实施例提供的约车订单处理方法的再一流程示意图，如图3所示，在上述S105之后，该方法还可以包括：

S301，在车辆到达目的地之后，生成第一约车订单的第一计费信息；

S302，在目标终端显示第一计费信息，以使用户根据第一计费信息支付费用，目标终端包括第二显示屏或用户的移动终端。

基于上述实施例，通过在车辆抵达目的地后生成第一计费信息，并将第一计费信息在第二显示屏或用户的移动终端上显示，从而提示用户需要根据第一计费信息支付相关的费用，准确地将第一计费信息告知了用户。

在S301中，若车辆的实时位置与目的地一致，则可以认为车辆抵达目的地；在车辆抵达目的地后，生成第一约车订单的第一计费信息。

作为示例，第一计费信息可以包括总费用信息和目标单项费用，其中，目标单项费用可以包括长途费、等待费以及跨城费中的至少一项。

在S302中，将第一计费信息显示在目标终端上，使得用户可以看见第一计费信息，并根据第一计费信息支付相关费用。

作为示例，目标终端可以包括第二显示屏或用户的手机等移动终端。

为了能有效地解决用户因订单出现异常的投诉，本申请还提供了约车订单处理方法的另一种实现方式。

如图3所示，该方法还可以包括：

S303，接收第一约车订单的订单计费异常请求；

S304，对订单计费异常请求进行异常判定，生成异常判定结果；

S305，将判定结果发送至目标终端。

基于上述实施例，通过对异常请求信息进行判定，并将判定结果发送给目标终端，用于告知用户判定结果，及时有效地解决了用户的异常投诉问题，提高了用户使用车辆的满意度。

在S303中，用户在收到第一计费信息后，若对第一计费信息产生疑问，则可以通过目标终端发起订单计费异常请求，车辆接收订单计费异常请求。

作为示例，订单计费异常请求的原因可以包括：用户未上车仍计费、用户认为车辆存在绕路行为导致费用不合理、订单取消仍收取费用等。

在S304中，车辆在接收到订单计费异常请求后，会根据第一约车订单的订单信息，对整个执行第一约车订单的过程进行判定，并因此生成判定结果。

在S305中，通过将判定结果发送给目标终端，使得第二显示屏或用户的手机等移动终端可以显示该判定结果。

为了能更准确体现对于订单计费异常请求的判定方法，下面依次列举用户未上车判责、用户取消订单判责和订单绕路判责。

如图4示出了本申请一个实施例提供的约车订单处理方法的再一流程示意图，如图4所示，具体地，该方法用于用户未上车判责，该方法还可以包括：

S401，接收针对第一约车订单的未上车申诉信息；

S402，获取用户对预设控件的确认操作时车辆的第一位置；

S403，比较起始地和第一位置之间的距离是否超过预设距离；

S404，在确定起始地和第一位置之间的距离不超过预设距离情况下，向用户的移动终端发送第一信息，第一信息用于提示用户未上车申诉信息申诉未成功；

S405，在确定起始地和第一位置之间的距离超过预设距离且第一约车订单的费用已支付的情况下，向收费端发送第二信息，第二信息用于通知收费端将已收取的第一约车订单的费用退还给用户；

S406，在确定起始地和第一位置之间的距离超过预设距离且第一约车订单的费用未支付的情况下，向用户的移动终端发送第三信息，第三信息用于提示第一约车订单免单。

基于上述实施例，通过比较在用户对预设控件执行确认操作时车辆的第一位置和起始地两者之间的距离，如果小于预设距离，则可以认为车辆已经到达起始地，则对预设控件执行确认操作的为用户，用户已上车；反之超出预设距离则认为用户没有上车，责任方在车辆，需要给用户退款或免单，降低了错收用户费用事件发生的可能，提高了用户使用车辆时的满意度。

在S401中，用户通过手机发送未上车申诉信息。

在S402中，通过调取车辆运行日志，获取在用户对预设控件执行确认操作时，车辆当时所在的第一位置。

在S403中，判断较第一位置和起始地之间的距离是否超过预设距离，具体地，由于考虑定位的准确性以及用户在等待车辆过程中的运动，因此需要设置预设距离来补偿上述因素所带来的差值。

在S404中，如果起始地和第一位置之间的距离不超过预设距离，则认为车辆已经抵达起始地接到用户，对预设控件执行确认操作的是用户，因此用户申诉未上车则不符合事实，需要向用户的移动终端返回第一信息，告知用户申诉不成功。

在S405中，同理，如果距离超过预设距离，则认为车辆没有抵达起始地接用户，用户未上车；因此，对预设控件执行确认操作的也不会是用户，如果用户已经根据第一费用信息支付了费用，则给银行发送第二信息，让银行将第一约车订单的费用返回给用户的支付账户。

在S406中，同理，如果用户没有上车且没有支付第一约车订单的费用，则第一约车订单免单，无需用户根据第一费用信息支付费用。

如图5示出了本申请一个实施例提供的约车订单处理方法的再一流程示意图，如图5所示，具体地，该方法用于用户取消订单判责，该方法还可以包括：

S501，获取第二订单的取消时长，取消时长为第二订单的生成时刻到取消时刻之间的时长；

S502，在持续时长大于预设时长的情况下，获取网约车抵达第二订单的起始地的第一时刻；

S503，根据第一时刻，确定车辆是否迟到；

S504，在确定车辆迟到的情况下，判定车辆需要承担第二订单取消的责任，用户无需承担第二订单取消的责任；

S505，在确定车辆未迟到的情况下，判定车辆无需承担第二订单取消的责任，用户需要承担第二订单取消的责任。

基于上述实施例，通过先比较取消时长和预设时长，在确认取消时长大于预设时长的情况下，再通过判断车辆是否迟到，车辆如果迟到则认为车辆担责，否则则为用户担责；通过两次比较判断，清晰准确地对取消订单责任进行了划分，切实保护了用户的合法权益，提高了用户使用车辆的满意程度。

在S501中，用户通过手机取消第二订单，为了辨别取消订单的责任，车辆需要获取第二订单的取消时长。

作为示例，取消时长为第二订单的生成时刻到取消时刻之间的时长。

在S502中，第二订单的持续时长如果小于预设时长，则取消订单，用户及车辆对此均无责；如果持续时长大于预设时长，则需要获取网约车抵达第二订单起始地时的第一时刻做进一步判断。

在S503中，通过比较第一时刻和预计到达时刻，判断车辆抵达起始地时是否迟到。

在S504中，如果车辆没有迟到，则认定车辆无责，用户取消第二订单用户需要承担取消第二订单的责任，具体地，用户需要支付取消费。

在S505中，反之，如果车辆迟到，则认定车辆有责，用户无需承担取消第二订单的责任，即用户无需支付取消费。

具体地，如图5所示，如果第二订单的订单状态为取消，则在上述S501之前，该方法还可以包括

S506，获取车辆的实时位置信息；

S507，根据实时位置信息判断车辆是否抵达第二订单的起始地；

S508，若车辆抵达第二订单的起始地，则向用户的移动终端发送第四信息，第四信息用于提示用户车辆已经抵达起始地。

基于上述实施例，通过抵达后进一步联系用户，告知用户抵达起始地，以使得用户能够及时乘坐车辆，既有效地提高了车辆的服务态度，又能节约用户的等待时间，提高用户使用车辆的满意度。

在S506中，通过车载定位装置获取车辆的位置。

在S507中，获取车辆位置后，将车辆位置与起始的位置进行比较，判断车辆是否抵达第二订单起始地。

在S508中，如果车辆已经抵达起始地，则可以通过智能语音助手给用户手机拨打电话，告知用户车辆已经抵达第二订单中的起始地，使得用户可以尽快抵达起始地上车出发。

另外，本申请还提供一种订单绕路判责方法，具体地，当车辆抵达目的地后，通过比较车辆行驶路径与预设行驶路径之间的行驶距离差值、车辆行驶时间与预设行驶时间之间的行驶距离差值，以及行驶路径与地图导航路径之间的偏移次数，如果上述判定中，存在任意一项超出预设值，则可以认为订单绕路。

在确认订单绕路后，根据预设行驶路径生成第二计费信息，将第二计费信息发送给目标终端，使用户根据第二计费信息支付第二费用，而不是第一计费信息支付第一费用；如果用户已经根据第一计费信息支付第一费用，则比较第一计费用和第二费用之间的差值，将差值部分退回给用户的支付账户。

需要说明的是，上述本申请实施例描述的应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

基于相同的发明构思，本申请还提供了一种车辆。具体结合图6进行详细说明。

图6示出了本发明实施例提供的车辆60的硬件结构示意图。

如图6所示，该车辆60可以包括：

获取模块61，用于获取第一约车订单和当前车辆位置，第一约车订单包括起始地和目的地；

第一显示模块62，用于在第一显示屏显示第一约车订单的订单信息，并在第二显示屏上显示第一约车订单的目标界面，目标界面包括预设控件，预设控件用于使用户确认第一约车订单；

第一驱动模块63，用于在当前车辆位置与起始地不一致时，驱动车辆行驶至起始地；

接收模块64，用于接收用户对预设控件的确认操作；

第二驱动模块65，响应于确认操作，驱动车辆从起始地驶向目的地。

在本实施例提供的车辆60中，通过车辆的获取模块61在接收第一约车订单后，第一驱动模块63自动操作车辆驶向起始地等候乘客；并在乘客上车后，第一显示模块62主动将订单信息显示给乘客，接收模块64只有待乘客确认了订单信息后，第二驱动模块65才将乘客由起始地送至目的地，整个处理第一约车订单的过程中，无需司机接收订单并操作车辆，实现了车辆的自动化运行；如此，本方法可以适用于无人驾驶车辆，有利于实现车辆的自动化运行。

可选地，第二驱动模块65可以包括：

获取单元，用于获取车辆的实时位置信息以及从实时位置信息到目的地的路况信息；

规划单元，用于根据路况信息，规划从实时位置信息到目的地的路径，得到目标路径；

驱动单元，用于根据目标路径驱动车辆从起始地驶向目的地。

可选地，车辆还可以包括：

生成模块，用于在车辆到达目的地之后，生成第一约车订单的第一计费信息；

第二显示模块，用于在目标终端显示第一计费信息，以使用户根据第一计费信息支付费用，目标终端包括第二显示屏或用户的移动终端。

图7示出了本发明实施例提供的约车订单处理设备的硬件结构示意图。

约车订单处理设备可以包括处理器71以及存储有计算机程序指令的存储器72。

具体地，上述处理器71可以包括中央处理器(CPU)，或者特定集成电路(ApplicationSpecificIntegratedCircuit，ASIC)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

存储器72可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器72可包括硬盘驱动器(HardDiskDrive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(UniversalSerialBus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器72可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器72可在综合网关容灾设备的内部或外部。在特定实施例中，存储器72是非易失性固态存储器。

在特定实施例中，存储器72可包括只读存储器(ROM)，随机存取存储器(RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器72包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器71)时，其可操作来执行参考根据本申请的一方面的方法所描述的操作。

处理器71通过读取并执行存储器72中存储的计算机程序指令，以实现上述实施例中的任意一种约车订单处理方法。

在一个示例中，约车订单处理设备还可包括通信接口73和总线74。其中，如图所示，处理器71、存储器72、通信接口73通过总线74连接并完成相互间的通信。

通信接口73，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。

总线74包括硬件、软件或两者。举例来说而非限制，总线74可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无线带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围控件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线74可包括一个或多个总线74。尽管本申请实施例描述和示出了特定的总线74，但本申请考虑任何合适的总线74或互连。

该约车订单处理设备可以基于当前约车订单处理方法，从而实现结合图1～图7描述的约车订单处理方法和装置。

另外，本申请实施例还提供了一种计算机程序产品，包括计算机程序指令，计算机程序产品被处理器71执行时可实现前述方法实施例的步骤及相应内容。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (10)

1.一种约车订单处理方法，其特征在于，所述方法应用于车辆，所述车辆上设置有第一显示屏和第二显示屏，所述方法包括：

获取第一约车订单和当前车辆位置，所述第一约车订单包括起始地和目的地；

在所述第一显示屏显示所述第一约车订单的订单信息，并在所述第二显示屏上显示第一约车订单的目标界面，所述目标界面包括预设控件，所述预设控件用于使用户确认所述第一约车订单；

在所述当前车辆位置与所述起始地不一致时，驱动车辆行驶至所述起始地；

接收用户对所述预设控件的确认操作；

响应于所述确认操作，驱动车辆从所述起始地驶向所述目的地。

2.如权利要求1所述的约车订单处理方法，其特征在于，所述驱动车辆从所述起始地驶向所述目的地，包括：

获取车辆的实时位置信息以及从所述实时位置信息到目的地的路况信息；

根据所述路况信息，规划从所述实时位置信息到目的地的路径，得到目标路径；

根据所述目标路径驱动车辆从所述起始地驶向所述目的地。

3.如权利要求1所述的约车订单处理方法，其特征在于，所述方法还包括：

在车辆到达所述目的地之后，生成所述第一约车订单的第一计费信息；

在目标终端显示所述第一计费信息，以使用户根据所述第一计费信息支付费用，所述目标终端包括第二显示屏或用户的移动终端。

4.如权利要求3所述的约车订单处理方法，其特征在于，所述第一计费信息包括总费用信息和目标单项费用，所述目标单项费用包括长途费、等待费以及跨城费中的至少一项。

5.如权利要求3所述的约车订单处理方法，其特征在于，在所述在目标终端显示所述第一计费信息之后，所述方法还包括：

接收所述第一约车订单的订单计费异常请求；

对所述订单计费异常请求进行异常判定，生成异常判定结果；

将所述判定结果发送至所述目标终端。

6.如权利要求1所述的约车订单处理方法，其特征在于，所述方法还包括：

接收针对所述第一约车订单的未上车申诉信息；

获取用户对所述预设控件的确认操作时车辆的第一位置；

比较起始地和第一位置之间的距离是否超过预设距离；

在确定起始地和第一位置之间的距离不超过预设距离情况下，向所述用户的移动终端发送第一信息，所述第一信息用于提示所述用户所述未上车申诉信息申诉未成功；

在确定起始地和第一位置之间的距离超过预设距离且所述第一约车订单的费用已支付的情况下，向收费端发送第二信息，所述第二信息用于通知所述收费端将已收取的第一约车订单的费用退还给所述用户；

在确定起始地和第一位置之间的距离超过预设距离且所述第一约车订单的费用未支付的情况下，向所述用户的移动终端发送第三信息，所述第三信息用于提示所述第一约车订单免单。

7.如权利要求1所述的约车订单处理方法，其特征在于，所述方法还包括：

获取第二订单的取消时长，所述取消时长为所述第二订单的生成时刻到取消时刻之间的时长；

在所述持续时长大于预设时长的情况下，获取所述网约车抵达所述第二订单的起始地的第一时刻；

根据所述第一时刻，确定车辆是否迟到；

在确定车辆迟到的情况下，判定车辆需要承担所述第二订单取消的责任，用户无需承担所述第二订单取消的责任；

在确定车辆未迟到的情况下，判定车辆无需承担所述第二订单取消的责任，用户需要承担所述第二订单取消的责任。

8.如权利要求7所述的约车订单处理方法，其特征在于，在所述订单状态为取消的情况下，获取第二订单信息的取消时长之前，所述方法还包括：

获取所述车辆的实时位置信息；

根据所述实时位置信息判断所述车辆是否抵达所述第二订单的起始地；

若所述车辆抵达所述第二订单的起始地，则向所述用户的移动终端发送第四信息，所述第四信息用于提示用户所述车辆已经抵达所述起始地。

9.一种车辆，所述车辆包括：

获取模块，用于获取第一约车订单和当前车辆位置，所述第一约车订单包括起始地和目的地；

第一显示模块，用于在所述第一显示屏显示所述第一约车订单的订单信息，并在所述第二显示屏上显示第一约车订单的目标界面，所述目标界面包括预设控件，所述预设控件用于使用户确认所述第一约车订单；

第一驱动模块，用于在所述当前车辆位置与所述起始地不一致时，驱动车辆行驶至所述起始地；以及响应于所述确认操作，驱动车辆从所述起始地驶向所述目的地；

接收模块，用于接收用户对所述预设控件的确认操作；

第二驱动模块，用于响应于所述确认操作，驱动车辆从所述起始地驶向所述目的地。

10.一种约车订单处理设备，其特征在于，所述设备包括：处理器以及存储有计算机程序指令的存储器；

所述处理器执行所述计算机程序指令时实现如权利要求1-8中任意一项所述的约车订单处理方法。

Images