CN113393003B - 一种订单处理方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请涉及巡游车与网约车技术领域，尤其涉及一种订单处理方法、装置、服务器及存储介质。该方法包括：接收用户发送的订单请求；订单请求中包括用户设定的需求车型的信息；根据订单请求选取目标车辆发送派单信息；若用户设定的需求车型为网约车车型，则向目标车辆发送运营状态变更指令；运营状态变更指令用于使目标车辆变更运营状态。该订单处理方法通过将用户的网络约车订单直接派发给指定的目标车辆，并根据用户下单时所设定的需求车型向目标车辆发送指令，使目标车辆对其自身的运营状态进行变更，不仅避免了巡游出租汽车司机的挑单、拒载行为，保证用户能够出行便捷性，还确保了接单的车辆能够满足用户的需求，提高用户体验。

Description

一种订单处理方法、装置、服务器及存储介质

技术领域

本申请涉及巡游车与网约车技术领域，尤其涉及一种订单处理方法、装置、服务器及存储介质。

背景技术

巡游出租汽车是城市综合交通运输体系的组成部分，承担了补充城市公共交通运力的责任，为社会公众提供个性化运输服务。近年来，随着移动互联网行业的迅速发展，传统交通运输与互联网融合的行业新业态蓬勃发展，使得网络预约出租汽车俨然已经成为用户出行的一个重要方式。为了积极稳妥地推进出租汽车行业改革，鼓励创新，促进转型，更好地满足人民群众出行需求，《国务院办公厅关于深化改革推进出租汽车行业健康发展的指导意见》指出，抓住实施“互联网+”行动的有利时机，坚持问题导向，促进巡游出租汽车转型升级，规范网络预约出租汽车经营，推进两种业态融合发展。

现有技术中，传统的巡游出租汽车通过一些网络约车平台实现了承接网约订单。但这种实现方式仅仅是接单方式的改变，巡游出租汽车并不能完全替代网络预约出租汽车。在一些情境下，巡游出租汽车并不能满足需要真正网约车用户的需求。而且，现有的网络预约出租汽车并不具有线下接单能力。这就导致巡游出租汽车与网络预约出租汽车并不能很好的融合，甚至造成了巡游出租汽车与网络预约出租汽车经营上的相互对立，致使运力资源的浪费。

发明内容

本发明要解决的技术问题是现有的巡游出租汽车与网络预约出租汽车无法实现真正融合的问题。

为解决上述技术问题，第一方面，本申请实施例公开了一种订单处理方法，所述方法包括：

接收用户发送的订单请求；所述订单请求中包括所述用户设定的需求车型的信息；

根据所述订单请求选取目标车辆发送派单信息；

若所述用户设定的需求车型为网约车车型，则向所述目标车辆发送运营状态变更指令；所述运营状态变更指令用于使所述目标车辆变更运营状态。

进一步的，所述运营状态变更指令为车顶灯隐藏指令；所述向所述目标车辆发送运营状态变更指令，包括：

向所述目标车辆发送所述车顶灯隐藏指令，所述车顶灯隐藏指令用于使所述目标车辆将车顶灯隐藏。

进一步的，所述根据所述订单请求选取目标车辆发送派单信息，包括：

根据所述订单请求确定所述用户乘车地点预设范围内的待接单车辆集合；

根据设定的派单规则在所述待接单车辆集合中选取所述目标车辆；

将派单信息发送给所述目标车辆。

进一步的，所述根据所述订单请求确定所述用户乘车地点预设范围内的待接单车辆集合，包括：

根据所述订单请求确定所述用户乘车地点预设范围内接入网约平台的全部运营车辆；

在所述全部运营车辆中确定运营状态为空闲的车辆构成所述待接单车辆集合。

进一步的，所述待接单车辆集合包括至少一个待接单车辆；所述根据设定的派单规则在所述待接单车辆集合中选取所述目标车辆，包括：

获取所述待接单车辆的当前位置和可行驶距离；

根据所述当前位置、所述乘车地点和所述用户的目的地确定订单预估距离；

根据所述可行驶距离和所述订单预估距离确定所述目标车辆。

进一步的，所述向所述目标车辆发送运营状态变更指令之后，还包括：

接收所述目标车辆发送的订单完成信息；

根据所述订单完成信息向所述目标车辆发送车顶灯展示指令；所述车顶灯展示指令用于使所述目标车辆将隐藏的车顶灯展示出来。

进一步的，所述方法还包括：

若所述用户设定的需求车型为巡游车车型，则向所述目标车辆发送车顶灯显示更改指令；所述车顶灯显示更改指令用于使所述目标车辆的车顶灯所显示的载客状态更改为预约载客状态。

第二方面，本申请实施例公开了一种订单处理装置，所述装置包括：

接收模块，接收用户发送的订单请求；所述订单请求中包括所述用户设定的需求车型的信息；

派单信息发送模块，用于根据所述订单请求选取目标车辆发送派单信息；

指令发送模块，用于若所述用户设定的需求车型为网约车车型，则向所述目标车辆发送运营状态变更指令；所述运营状态变更指令用于使所述目标车辆变更运营状态。

在一个可选的实施例中，所述运营状态变更指令为车顶灯隐藏指令；指令发送模块包括：

车顶灯隐藏指令发送单元，用于向所述目标车辆发送所述车顶灯隐藏指令，所述车顶灯隐藏指令用于使所述目标车辆将车顶灯隐藏。

在一个可选的实施例中，派单信息发送模块包括：

待接单车辆集合确定单元，用于根据所述订单请求确定所述用户乘车地点预设范围内的待接单车辆集合；

目标车辆选取单元，用于根据设定的派单规则在所述待接单车辆集合中选取所述目标车辆；

发送单元，用于将派单信息发送给所述目标车辆。

在一个可选的实施例中，待接单车辆集合确定单元包括：

运营车辆确定子单元，用于根据所述订单请求确定所述用户乘车地点预设范围内接入网约平台的全部运营车辆；

空闲车辆确定子单元，用于在所述全部运营车辆中确定运营状态为空闲的车辆构成所述待接单车辆集合。

在一个可选的实施例中，所述待接单车辆集合包括至少一个待接单车辆；目标车辆选取单元包括：

位置获取子单元，用于获取所述待接单车辆的当前位置和可行驶距离；

距离确定子单元，用于根据所述当前位置、所述乘车地点和所述用户的目的地确定订单预估距离；

目标车辆确定单元，用于根据所述可行驶距离和所述订单预估距离确定所述目标车辆。

在一个可选的实施例中，所述装置还包括：

订单完成信息接收模块，用于接收所述目标车辆发送的订单完成信息；

车顶灯展示指令发送单元，用于根据所述订单完成信息向所述目标车辆发送车顶灯展示指令；所述车顶灯展示指令用于使所述目标车辆将隐藏的车顶灯展示出来。

在一个可选的实施例中，所述装置还包括：

车顶灯显示更改指令发送单元，用于若所述用户设定的需求车型为巡游车车型，则向所述目标车辆发送车顶灯显示更改指令；所述车顶灯显示更改指令用于使所述目标车辆的车顶灯所显示的载客状态更改为预约载客状态。

第三方面，本申请实施例公开了一种服务器，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行如上所述的订单处理方法。

第四方面，本申请实施例公开了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如上所述的订单处理方法。

本申请实施例提供的订单处理方法、装置、服务器及存储介质，具有如下技术效果：

该订单处理方法通过将用户的网络约车订单直接派发给指定的目标车辆，并根据用户下单时所设定的需求车型向目标车辆发送指令，使目标车辆对其自身的运营状态进行变更，不仅避免了巡游出租汽车司机的挑单、拒载行为，保证用户能够出行便捷性，还确保了接单的车辆能够满足用户的需求，提高用户体验。

附图说明

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

图1是本申请实施例提供的一种订单处理方法的应用环境的示意图；

图2是本申请实施例提供的一种订单处理方法的流程示意图；

图3是本申请实施例提供的一种订单处理方法的交互流程示意图；

图4是本申请实施例提供的一种根据订单请求选取目标车辆发送派单信息方法的流程示意图；

图5是本申请实施例提供的一种订单处理装置的结构示意图；

图6是本申请实施例提供的一种订单处理方法的服务器的硬件结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

网络预约出租汽车又称网约车，网约车通过接入网约车平台实现接单载客。巡游出租汽车又称巡游车，传统的巡游车通过在城市道路上巡游接受乘客的扬招，实现接单载客。网约车的能够满足用户在不同出行场景中的使用需求，为用户出行带来了极大的便利。然而，由于网约车平台通常采用抢单的方式派发用户的订单，因此，网约车存在服务供给和需求在时空分布上的不匹配的问题，产生了某些时段某些区域的网约车需求无法被满足，而另外一些时段的一些区域又存在网约车运力供给过剩的情况。而巡游车的经营通常受到政府的监管，服从政府对运力资源的调度分配，能够最大程度上满足公众利益。现有的巡游车也能够通过接入网约车平台进行接单，但是由于巡游车通常为统一试样，无法满足用户的个性化需求。本申请实施例针对网约车和巡游车的优点，提供了一种两车融合的方案。

请参阅图1，图1是本申请实施例提供的一种订单处理方法的应用环境的示意图，如图1所示，该应用环境可以包括用户终端101、服务器102和车载终端103。

本申请实施例中，用户通过用户终端101发送约车订单。可选的，用户终端101可以包括但不限于智能手机、台式计算机、平板电脑、笔记本电脑、智能音箱、数字助理、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、智能可穿戴设备等类型的电子设备。也可以为运行于上述电子设备的软体，例如应用程序、小程序等。可选的，电子设备上运行的操作***可以包括但不限于安卓***、IOS***、linux、windows、Unix等。

本申请实施例中，服务器102用于接收用户终端101发送的订单信息，并将订单信息派发给指定的车载终端103。可选的，服务器102可以为网约车平台的后台服务器。可选的，服务器102可以包括是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

本申请实施例中，车载终端103为设置在车辆上的远程通信终端。车载终端103能够接收服务器102发送的信息、指令等，在一些情况下能够根据服务器102发送的指令控制车载装置进行动作。车辆指的是接入网约车平台，能够提供约车服务的车辆。与现有技术中的巡游车和网约车所不同的是，本申请实施例中的车辆为既能充当巡游车又能充当网约车的两用车辆。在实际运营过程中，该车辆既能够在城市道路上巡游，以接受乘客在路边的扬招订单，又能够接入网约车平台，根据用户的需求变换为网约车，以接受网约订单。

此外，需要说明的是，图1所示的仅仅是本公开提供的订单处理方法的一种应用环境，在实际应用中，用户终端101可以为注册网约车平台的用户客户端，车载终端103可以为接入网约车平台的车辆，用户终端101和车载终端103的个数可以有很多个，图1所示的1个用户终端101和1个车载终端103并不能对本申请进行限定。

以下介绍本申请一种订单处理方法的具体实施例，图2是本申请实施例提供的一种订单处理方法的流程示意图，本说明书提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的***或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，该方法应用于服务器，可以包括以下步骤：

S201：接收用户发送的订单请求。

本申请实施例中，当用户需要预约网约车出行时，用户通过其所持有的用户终端向服务器发送订单请求。订单请求中包括用户设定的需求车型的信息。需求车型指的是用户所需要用车的类型，包括网约车和巡游车。

S203：根据订单请求选取目标车辆发送派单信息。

本申请实施例中，服务器接收到用户终端所发送的订单请求后，根据订单请求中所包含的订单信息，在接入网约车平台的车辆中选取目标车辆来派发用户的订单。

S205：若用户设定的需求车型为网约车车型，则向目标车辆发送运营状态变更指令。

本申请实施例中，服务器在确定好目标车辆后，再根据用户的订单请求中所设定的需求车型对车辆进行控制处理，确保车型符合用户需求。服务器确定用户设定的需求车型为网约车车型时，服务器会向目标车辆发送运营状态变更指令。运营状态变更指令用于使目标车辆变更运营状态。

基于上述应用于服务器的订单处理方法，以下对服务器执行订单处理方法的具体交互过程进行说明。图3是本申请实施例提供的一种订单处理方法的交互流程示意图，如图3所示，该订单处理方法的交互侧分别为用户终端、服务器和车载终端，包括以下步骤：

S301：用户终端发送订单请求。

本申请实施例中，用户在使用用户终端进行网络约车之前，用户通过用户终端与服务器进行交互，提交身份验证信息以完成账户注册，然后再通过登录账户在网约车平台进行网络约车。当用户需要预约网约车出行时，用户通过其所持有的用户终端向服务器发送订单请求。订单请求中除了包括乘车出发地、乘车目的地和乘车时间等订单基础信息之外，还包括用户设定的需求车型的信息。需求车型指的是用户所需要用车的类型，主要分为网约车和巡游车。这里所说的网约车指的是具有常见私家车外形的车辆，巡游车指的是与平常道路上可见的巡游车外形相同的车辆。在一些场景下，比如用户出席商务场合时，通过网约车到达目的地显然更加恰当。再如，在一些城市中，网约车的计费要比巡游车计费便宜，用户更倾向于使用网约车出行。再如，一些用户会认为巡游车更安全，更倾向于使用巡游车出行。基于上述场景，用户在发送订单请求的时候会预先设定所需要用车的车型。在现有技术中，显然只能够根据用户所设定的需求车型，为用户匹配相应的车型。即如果用户设定的需求车型为网约车车型，网约车平台只能为用户匹配网约车，如果用户设定的需求车型为巡游车车型，网约车平台只能为用户匹配巡游车。而本申请实施例中，由于接入网约车平台的车辆为两用融合车辆，该车辆既能充当网约车又能作为巡游车。因此，当用户的订单分配给车辆时，针对用户所设定的需求车型，可通过控制车载装置动作，以实现车辆外形的变换，使其外形呈现为巡游车或网约车。

需要说明的是，尽管本申请中的车辆既能充当网约车又能作为巡游车，接入网约车平台的车辆并不仅限于上述两用车辆，也可以同时接入普通的网约车和巡游车。在一些实施例中，两用车辆也可以作为网约车或巡游车的补充，当用户设定的需求车型运力不足时，可以匹配该两用车型作为运力的补充。

本申请实施例中，用户终端向服务器发送订单请求，与之对应的，服务器接收用户发送的订单请求。服务器根据订单请求中包括的用户所设定的需求车型的信息进行进一步的处理。

S303：服务器根据订单请求选取目标车辆发送派单信息。

本申请实施例中，服务器接收到用户终端所发送的订单请求后，根据订单请求中所包含的订单信息，在接入网约车平台的车辆中选取目标车辆来承接该笔订单。在一些场景中，比如某个商圈在出行高峰时段，在一个时间段内，多个用户同时向网约车平台发布订单，如果是通过司机抢单来派发订单的话，势必会造成出行距离较长的订单被接单，而出行距离较近的订单无人问津的情况。本申请实施例中，服务器直接选取目标车辆进行派单，而不是通过巡游车司机抢单的形式进行派单，能够有效避免司机的挑单、拒载的行为。

本申请实施例中，服务器根据订单信息中对车辆的偏好信息以及网约车平台的派单规则来选取目标车辆派发订单。图4是本申请实施例提供的一种根据订单请求选取目标车辆发送派单信息方法的流程示意图，如图4所示，根据订单请求选取目标车辆发送派单信息，包括：

S401：根据订单请求确定用户乘车地点预设范围内的待接单车辆集合。

本申请实施例中，服务器首先在订单请求所包含的订单信息中获取到用户的乘车地点，然后再确定用户乘车地点一定距离范围内，能够承接订单的车辆，构成待接单车辆集合。作为一种可选的实施方式，服务器根据订单请求确定用户乘车地点预设范围内的待接单车辆集合，首先，服务器需要根据订单请求确定用户乘车地点预设范围内接入网约平台的全部运营车辆。然后，服务器在全部运营车辆中确定运营状态为空闲的车辆构成待接单车辆集合。在用户乘车地点的附近可能存在多个接入网约车平台的车辆，这些车辆中的运营状态包括空闲状态、载客状态以及停止运营状态。运营状态为空闲的车辆在网约车平台上会对应显示该车辆正在等待接单。运营状态为载客的车辆分为两种，一种是正在完成网约车平台所派发的订单，此时服务器会有相应的记录信息。另一种是车辆在道路上巡游时接受了乘客的扬招订单。空驶车辆可以接受扬招订单，开始服务后立即向网约车平台上报订单信号，服务器会记录该车辆为载客状态。一般来说，处于载客状态的车辆网约车平台将不再向该车辆派发网约订单。在一些实施例中，处于载客状态的车辆也可以通过根据其行程信息、路径信息等预估订单结束时间，当订单结束时间在预设范围内，网约车平台也可以提前派发订单。运营状态为停止运营的车辆也会记录在服务器中，服务器在确定待接单车辆集合时也会将这部分车辆过滤掉。

需要说明的是，对于一些接入网约车平台的纯电动车辆来说，当车辆正在充电时也可以设置为空闲状态，以等待网约订单，从而实现停车不停运，提高司机的接单率。

在一些场景中，例如出行高峰期，可能会出现用户乘车地点附近没有运营状态为空闲的待接单车辆。此时，可以通过扩大筛选范围，以覆盖更多的车辆。当然针对远距离接单的司机，网约车平台也可以指定一定的奖励措施，以提高司机的接单积极性。除了上述措施之外，服务器也可以根据某个区域预设时间段内的订单数量与空闲车辆的数量对比，进行车辆调度。作为一种可选的实施方式，服务器首先确定预设区域内的用户在预设时间段内发送的订单数量，然后再获取预设区域内运营状态为空闲的车辆数量，如果车辆数量小于等于订单数量，则向接入网约平台的全部运营车辆发送调度信息。调度信息可以是针对某些车辆的强制执行信息，也可以是引导性的广播信息，从而使车辆前往预定区域，增加该区域能够接单车辆的数量。

S403：根据设定的派单规则在待接单车辆集合中选取目标车辆。

本申请实施例中，服务器根据平台设定的派单规则在待接单车辆集合中选取目标车辆。作为一种可选的实施方式，待接单车辆集合包括至少一个待接单车辆。服务器根据设定的派单规则在待接单车辆集合中选取目标车辆，包括：获取待接单车辆的当前位置和可行驶距离。根据当前位置、乘车地点和用户的目的地确定订单预估距离。根据可行驶距离和订单预估距离确定目标车辆。具体的，服务器实时监控车辆的运转状态，当服务器在选取目标车辆进行派单时首先要确定车辆的可行驶距离。比如，纯电动车辆在完成订单途中电量不足，将会给用户带来不好的体验。因此，当车辆的剩余电量不足以支撑远距离订单时，那就不能选择该车辆承接远距离订单。服务器根据车辆的当前位置，用户的乘车地点以及目的地计算出待接单集合中每个车辆完成该订单需要行驶的距离，通过与车辆各自的可行驶距离进行比对，确定能够完成订单的车辆作为目标车辆。

在一些实施例中，在保证车辆的可行驶距离能够完成订单的前提下，服务器根据用户的订单请求中所设定的偏好信息，比如要求司机接单量、服务评分、驾龄等大于预设值，服务器根据上述偏好信息对待接单车辆进行筛选，从而得到符合用户预期的目标车辆。在另一些实施例中，服务器也可以通过将可供选的车辆信息发送给用户终端，用户可以自主选择承接订单的车辆。

S405：将派单信息发送给目标车辆。

本申请实施例中，服务器确定目标车辆后，将派单信息发送给目标车辆，通知司机完成订单，同时向用户终端发送目标车辆的信息，以提醒用户。

S305：服务器判断用户设定的需求车型是否为网约车车型。

本申请实施例中，服务器在确定好目标车辆后，再根据用户的订单请求中所设定的需求车型对车辆进行控制处理，确保车型符合用户需求。可选的，服务器判断用户设定的需求车型是否为网约车车型，若果是，则执行步骤S307，如果否，则转至步骤S309。

需要说明的是，上述对用户需求车型的判断过程，是针对网约和巡游两用车来说的。对于普通的网约车和巡游车而言，网约车平台可以在确定待接单车辆集合时，根据用户设定的需求车型直接确定相应车型的待接单车辆集合。作为一种示例，如果用户设定的需求车型是网约车，服务器需要根据订单请求确定用户乘车地点预设范围内接入网约平台的全部的正在运营的网约车车辆。然后，服务器在全部网约车车辆中确定运营状态为空闲的网约车车辆构成待接单车辆集合。

S307：服务器向目标车辆发送运营状态变更指令。

本申请实施例中，服务器确定用户设定的需求车型为网约车车型时，服务器会向目标车辆发送运营状态变更指令。运营状态变更指令用于使目标车辆变更运营状态。可选的，运营状态变更指令可以跟派单信息同时发送给目标车辆。可选的，运营状态变更指令可以在派单信息发送给目标车辆之后，服务器再独向车载终端发送运营状态变更指令。在一些实施例中，运营状态变更指令也可以包含在派单信息中，即派单信息中携带有运营状态变更指令，车载终端在接收到派单信息后，通过解析得到运营状态变更指令。车辆上设置有标志车辆运营状态的车载装置，该装置也可以是区分网约车与巡游车的装置，比如车顶灯。通常来说，网约车与巡游车在外形上的主要区别为，巡游车的车身顶部设置有用于显示运营状态的车顶灯，而网约车的车身顶部没有车顶灯。在一个可选的实施方式中，运营状态变更指令为车顶灯隐藏指令，服务器向目标车辆发送车顶灯隐藏指令，目标车辆中的车载终端接收到车顶灯隐藏指令后，控制目标车辆车顶灯隐藏起来。作为一种可选的实施方式，目标车辆的车顶灯通过升降机构安装在车身上，当车载终端接收到车顶灯隐藏指令后，控制升降机构升降，进而带动车顶灯降下，使车顶灯隐藏在车身内部。作为另一种可选的实施方式，目标车辆的车顶灯通过折叠机构安装在车身上，当车载终端接收到车顶灯隐藏指令后，控制折叠机构带动车顶灯翻转，从而使车顶灯隐藏在车身内部。

应当理解的是，车载装置为车顶灯仅作为一种可选的实施方式，本申请实施中用于区分网约车与巡游车的装置的车载装置并不仅限于车顶灯，也可以为其他的车载装置。例如，车辆的两侧车门上设置有标志车辆类型的显示屏，显示屏上可以显示车辆的载客状态，当车载终端接收到运营状态变更指令后，通过更改显示屏上的显示内容，比如显示为车身相同的颜色，使车辆的外观与网约车一致。

S309：服务器向目标车辆发送车顶灯显示更改指令。

本申请实施例中，服务器确定用户设定的需求车型不是网约车车型，即服务器确定用户设定的需求车型为巡游车车型时，服务器会向目标车辆发送车顶灯显示更改指令。车顶灯显示更改指令用于使目标车辆的车顶灯所显示的载客状态更改为预约载客状态。正常情况下，车辆作为巡游车在道路上巡游接受乘客的扬招订单，同时等待接受网约车平台派发网约订单。车辆上的车顶灯用于展示车辆的载客状态。作为一种示例，车顶灯上显示的车辆载客状态可以包括“空车”、“载客”、“网约”等状态，在道路边进行扬招的乘客通过观察车顶灯上显示的字样即可知道该车辆的载客状态。当服务器确定用户设定的需求车型为巡游车车型时，服务器会向目标车辆发送车顶灯显示更改为“网约”指令。在一些实施例中，车顶灯不仅限于通过显示字样来表明车辆载客状态，也可以通过显示不同的颜色来表明车辆的载客状态。例如，通过显示绿色表示车辆为空闲状态，通过显示红色表示车辆为载客中的状态，通过显示黄色表示车辆为网络预约的状态。服务器通过向目标车辆发送车顶灯显示更改指令，在车辆接受网约订单时，变更其线下运营状态，避免给线下乘客造成拒载误解。而且，车辆的载客状态在服务器上进行记录，实现了车辆线上和线下的实际运营载客状态的统一，服务器根据车辆的实际载客状态，方便对车辆进行派单，减少派单错误。

本申请实施例中，当车辆完成当前订单后，通过车载终端向服务器发送订单完成信息，以再次进入等待接单的状态。作为一种可选的实施方式，服务器接收目标车辆上的车载终端发送的订单完成信息。服务器根据订单完成信息向目标车辆发送车顶灯展示指令，车顶灯展示指令用于使目标车辆将隐藏的车顶灯展示出来。车载终端向服务器发送订单完成信息时，服务器获知目标车辆已完成前一订单，然后会根据车辆位置再次为车辆匹配订单。或者车辆通过将车顶灯展示出来，在道路上巡游，以接收扬招订单。可选的，车载终端向服务器发送的订单完成信息包括车辆完成订单期间的影音资料、订单数据等信息。

本申请实施例所述的订单处理方法，可满足用户在不同出行场景中的使用需求，为用户出行带来了极大的便利。

本申请实施例还提供了一种订单处理装置，图5是本申请实施例提供的一种订单处理装置的结构示意图，如图5所示，该装置包括：

接收模块501，接收用户发送的订单请求；订单请求中包括用户设定的需求车型的信息。

派单信息发送模块503，用于根据订单请求选取目标车辆发送派单信息。

指令发送模块505，用于若用户设定的需求车型为网约车车型，则向目标车辆发送运营状态变更指令；运营状态变更指令用于使目标车辆变更运营状态。

在一个可选的实施例中，运营状态变更指令为车顶灯隐藏指令；指令发送模块505包括：

车顶灯隐藏指令发送单元，用于向目标车辆发送车顶灯隐藏指令，车顶灯隐藏指令用于使目标车辆将车顶灯隐藏。

在一个可选的实施例中，派单信息发送模块503包括：

待接单车辆集合确定单元，用于根据订单请求确定用户乘车地点预设范围内的待接单车辆集合。

目标车辆选取单元，用于根据设定的派单规则在待接单车辆集合中选取目标车辆。

发送单元，用于将派单信息发送给目标车辆。

在一个可选的实施例中，待接单车辆集合确定单元包括：

运营车辆确定子单元，用于根据订单请求确定用户乘车地点预设范围内接入网约平台的全部运营车辆。

空闲车辆确定子单元，用于在全部运营车辆中确定运营状态为空闲的车辆构成待接单车辆集合。

在一个可选的实施例中，待接单车辆集合包括至少一个待接单车辆；目标车辆选取单元包括：

位置获取子单元，用于获取待接单车辆的当前位置和可行驶距离。

距离确定子单元，用于根据当前位置、乘车地点和用户的目的地确定订单预估距离。

目标车辆确定单元，用于根据可行驶距离和订单预估距离确定目标车辆。

在一个可选的实施例中，装置还包括：

订单完成信息接收模块，用于接收目标车辆发送的订单完成信息。

车顶灯展示指令发送单元，用于根据订单完成信息向目标车辆发送车顶灯展示指令；车顶灯展示指令用于使目标车辆将隐藏的车顶灯展示出来。

在一个可选的实施例中，装置还包括：

车顶灯显示更改指令发送单元，用于若用户设定的需求车型为巡游车车型，则向目标车辆发送车顶灯显示更改指令；车顶灯显示更改指令用于使目标车辆的车顶灯所显示的载客状态更改为预约载客状态。

本申请实施例中的装置与方法实施例基于同样地申请构思。

本申请实施例所提供的方法实施例可以在计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图6是本申请实施例提供的一种订单处理方法的服务器的硬件结构框图。如图6所示，该服务器600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(Central Processing Units，CPU)610(处理器610可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器630，一个或一个以上存储应用程序623或数据622的存储介质620(例如一个或一个以上海量存储设备)。其中，存储器630和存储介质620可以是短暂存储或持久存储。存储在存储介质620的程序可以包括一个或一个以上模块，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器610可以设置为与存储介质620通信，在服务器600上执行存储介质620中的一系列指令操作。服务器600还可以包括一个或一个以上电源660，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口640，和/或，一个或一个以上操作***621，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

输入输出接口640可以用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器600的通信供应商提供的无线网络。在一个实例中，输入输出接口640包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，输入输出接口640可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

本领域普通技术人员可以理解，图6所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器600还可包括比图6中所示更多或者更少的组件，或者具有与图6所示不同的配置。

本申请的实施例还提供了一种计算机可读存储介质，存储介质中存储有至少一条指令或至少一段程序，至少一条指令或至少一段程序由处理器加载并执行以实现如上所述的订单处理方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例所述的订单处理方法，可满足用户在不同出行场景中的使用需求，为用户出行带来了极大的便利。该订单处理方法通过将用户的网络约车订单直接派发给指定的目标车辆，并根据用户下单时所设定的需求车型向目标车辆发送指令，使目标车辆对其自身的运营状态进行变更，不仅避免了巡游车司机的挑单、拒载行为，保证用户能够出行便捷性，还确保了接单的车辆能够满足用户的需求，提高用户体验。通过统一车辆的线上线下运营状态，提高车辆的接单率。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (7)

1.一种订单处理方法，其特征在于，所述订单处理方法用于目标车辆，所述目标车辆是能够用作巡游车和网约车的两用车辆，当用户的订单分配给所述目标车辆时，根据用户所设定的需求车型，通过控制车顶灯动作，以实现目标车辆的外形的变换，使目标车辆外形呈现为巡游车或网约车；

所述方法包括：

接收用户发送的订单请求；所述订单请求中包括所述用户设定的需求车型的信息；

根据所述订单请求选取目标车辆发送派单信息；

若所述用户设定的需求车型为网约车车型，则向所述目标车辆发送车顶灯隐藏指令；所述车顶灯隐藏指令用于使所述目标车辆将车顶灯隐藏；所述车顶灯是能够区分网约车与巡游车的装置；

若所述用户设定的需求车型为巡游车车型，则向所述目标车辆发送车顶灯显示更改指令；所述车顶灯显示更改指令用于使所述目标车辆的车顶灯所显示的载客状态更改为预约载客状态；

所述向所述目标车辆发送车顶灯隐藏指令之后，还包括：

接收所述目标车辆发送的订单完成信息；

根据所述订单完成信息向所述目标车辆发送车顶灯展示指令；所述车顶灯展示指令用于使所述目标车辆将隐藏的所述车顶灯展示出来。

2.根据权利要求1所述的订单处理方法，其特征在于，所述根据所述订单请求选取目标车辆发送派单信息，包括：

根据所述订单请求确定所述用户乘车地点预设范围内的待接单车辆集合；

根据设定的派单规则在所述待接单车辆集合中选取所述目标车辆；

将派单信息发送给所述目标车辆。

3.根据权利要求2所述的订单处理方法，其特征在于，所述根据所述订单请求确定所述用户乘车地点预设范围内的待接单车辆集合，包括：

根据所述订单请求确定所述用户乘车地点预设范围内接入网约平台的全部运营车辆；

在所述全部运营车辆中确定运营状态为空闲的车辆构成所述待接单车辆集合。

4.根据权利要求2或3所述的订单处理方法，其特征在于，所述待接单车辆集合包括至少一个待接单车辆；所述根据设定的派单规则在所述待接单车辆集合中选取所述目标车辆，包括：

获取所述待接单车辆的当前位置和可行驶距离；

根据所述当前位置、乘车地点和所述用户的目的地确定订单预估距离；

根据所述可行驶距离和所述订单预估距离确定所述目标车辆。

5.一种订单处理装置，其特征在于，所述订单处理装置用于目标车辆，所述目标车辆是能够用作巡游车和网约车的两用车辆，当用户的订单分配给所述目标车辆时，根据用户所设定的需求车型，通过控制车顶灯动作，以实现目标车辆的外形的变换，使目标车辆外形呈现为巡游车或网约车；所述装置包括：

接收模块，接收用户发送的订单请求；所述订单请求中包括所述用户设定的需求车型的信息；

派单信息发送模块，用于根据所述订单请求选取目标车辆发送派单信息；

第一指令发送模块，用于若所述用户设定的需求车型为网约车车型，则向所述目标车辆发送车顶灯隐藏指令；所述车顶灯隐藏指令用于使所述目标车辆将车顶灯隐藏；所述车顶灯是能够区分网约车与巡游车的装置；

第二指令发送模块，用于若所述用户设定的需求车型为巡游车车型，则向所述目标车辆发送车顶灯显示更改指令；所述车顶灯显示更改指令用于使所述目标车辆的车顶灯所显示的载客状态更改为预约载客状态；

订单完成信息接收模块，用于接收所述目标车辆发送的订单完成信息；

车顶灯展示指令发送单元，用于根据所述订单完成信息向所述目标车辆发送车顶灯展示指令；所述车顶灯展示指令用于使所述目标车辆将隐藏的所述车顶灯展示出来。

6.一种服务器，其特征在于，包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行如权利要求1-4任一所述的订单处理方法。

7.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或至少一段程序由处理器加载并执行以实现如权利要求1-4任一所述的订单处理方法。