申请/专利权人：腾讯科技(深圳)有限公司

申请日：2019-05-08

公开（公告）日：2024-06-04

公开（公告）号：CN110399999B

主分类号：G06Q10/0631

分类号：G06Q10/0631;G06Q10/047;G06Q30/0601;G06Q50/40

优先权：

专利状态码：有效-授权

法律状态：2024.06.04#授权;2020.12.01#实质审查的生效;2019.11.01#公开

摘要：本申请提供了一种乘车服务处理方法、装置、设备及存储介质，其中，所示方法包括：接收多个乘车订单；确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；从所述候选路线中确定目标路线；将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。通过本申请，能够提升多用户出行场景中的车辆利用率。

主权项：1.一种乘车服务处理方法，其特征在于，所述方法包括：接收多个乘车订单；确定满足以下条件的乘车订单，以形成相同行程订单集合：上车地点所属的上车区域相同；下车地点所属的下车区域相同；乘车时间在服务时间范围内；基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；基于所述候选路线对应的乘车订单和所述乘车订单对应的接送顺序，确定所述候选路线对应以下至少之一的影响因素：乘客数量；所述相同行程的里程数；所述相同行程的时长；接送乘客的里程数和接送乘客的时长；基于每个影响因素对应的权重将每个影响因素进行加权，得到所述候选路线的决策值；对各所述候选路线的决策值进行排序，并将决策值最小的候选路线确定为目标路线；将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线；当所述目标路线对应的乘客数量小于所述待调度车辆的载客量时，将在所述待调度车辆的接单截止时间之前接收的，且确定满足以下条件的新乘车订单为目标乘车订单：所述待调度车辆到达所述新乘车订单对应的上车地点的时间，与所述新乘车订单对应的乘车时间的时间差小于时间差阈值；所述新乘车订单与所述待调度车辆的已分配乘车订单的乘客数量小于或等于所述待调度车辆的载客量；基于所述目标乘车订单对原始的所述目标路线进行更新，将得到的新目标路线发送给所述待调度车辆以替换原始的所述目标路线；当确定所述乘车订单超出服务能力时，基于符合所述服务能力的服务时间范围和服务地点范围确定推荐信息，其中，所述推荐信息中包括推荐上车地点、推荐下车地点和推荐乘车时间至少之一；将所述推荐信息发送给乘客终端。

全文数据：乘车服务处理方法、装置、设备及存储介质技术领域本申请涉及智能交通技术领域，尤其涉及一种乘车服务处理方法、装置及存储介质。背景技术用户乘车出行的行程是个性化的，例如对于跨城市的出行来说，虽然很多用户的出发城市和目的城市可能相同，但是具体的上车地点和下车地点却存在差异，因此轨道交通无法满足用户的这种个性化的行程需求，用户购置私家车辆出行是实现个性化行程的一种常见方案。而随着车辆保有量不断攀升，对交通路网、停车场等相关社会交通资源造成极大压力，个性化的行程需求与有限社会交通资源之间的矛盾日益凸显。相关技术中缺少提升车辆利用率的技术方案以解决上述矛盾。发明内容本申请实施例提供一种乘车服务处理方法、装置、设备及存储介质，能够提升多用户出行场景中的车辆利用率。本申请实施例的技术方案是这样实现的：本申请实施例提供一种乘车服务处理方法，包括：接收多个乘车订单；确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；从所述候选路线中确定目标路线；将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。本申请实施例提供一种乘车服务处理方法，包括：获取乘车的上车地点、下车地点和乘车时间；根据所述上车地点、下车地点和乘车时间生成乘车订单；发送所述乘车订单到服务器，以使所述服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，从所述候选路线中确定目标路线；接收所述服务器发送的目标路线。本申请实施例提供一种乘车服务处理装置，包括：第一接收模块，用于接收多个乘车订单；第一确定模块，用于确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；第二确定模块，用于基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；第三确定模块，用于从所述候选路线中确定目标路线；第一发送模块，用于将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。本申请实施例提供一种乘车服务处理装置，包括：第四获取模块，用于获取乘车的上车地点、下车地点和乘车时间；订单生成模块，用于根据所述上车地点、下车地点和乘车时间生成乘车订单；第二发送模块，用于发送所述乘车订单到服务器，以使所述服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，从所述候选路线中确定目标路线；第二接收模块，用于接收所述服务器发送的目标路线。本申请实施例提供一种乘车服务处理设备，包括：存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的乘车服务处理方法。本申请实施例提供一种存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的乘车服务处理方法。本申请实施例具有以下有益效果：服务器根据相同行程来对乘车订单进行整合，并基于路线决策的影响因素确定目标路线；不仅能够充分利用待调度车辆的载客能力，还能保证派发给待调度车辆的订单是属于相同行程的最佳组合，从而能够使得车辆以最佳行程接送乘客，进而缩短乘客的出行时间并降低出行成本。附图说明图1为本申请实施例乘车服务处理方法的网络架构示意图；图2为本申请实施例提供的服务器的一个可选的结构示意图；图3为本申请实施例提供乘车服务处理方法的一个实现流程示意图；图4为本申请实施例确定目标路线的实现流程示意图；图5为本申请实施例乘车服务处理方法的又一个实现流程示意图；图6A为本申请实施例乘车服务处理方法的再一个实现流程示意图；图6B为本申请实施例乘客端选择用车时间的界面示意图；图6C为本申请实施例乘客输入上下车站点的界面示意图；图6D为本申请实施例输出城市选择的界面示意图；图6E为本申请实施例输入下车地点的界面示意图；图6F为本申请实施例进行行程确认的界面示意图；图6G为本申请实施例支付界面示意图；图6H为本申请实施例显示行程信息的界面示意图；图6I为本申请实施例在行程中的界面示意图；图6J为本申请实施例行程结束后的评价界面示意图；图7为本申请实施例乘客订单处理的实现时序示意图；图8为本申请实施例提供的乘客终端的一个可选的结构示意图。具体实施方式为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。为了更好地理解本申请实施例中提供的乘车服务处理方法，首先对相关技术中轨道交通支持城际乘车的方案进行分析说明。第一种乘车方案，应用于线下购票的场景：当乘客需要从城市A至城市B时，乘客为了确保自己出行得到保障，需要提前至城市A车站按照出行日期，现场购买车票。在出行日期当日，乘客先从出发点自行前往城市A车站。同样地，为避免因为路上堵车等异常导致未能赶上车辆，乘客需要提前一定的时间前往车站。上车后通过长途客运到达城市B车站，再通过城市B车站枢纽到达目的地。对于该乘车方案来说，除去从城市A车站到城市B车站之间的路程之外，乘客还需要完成两段来回汽车站的购票路程，一段从出发点去往出发地汽车站的路程，一段从目的地汽车站至目的地的路程。共计多出4段的路程，那么也就多出4段路程的时间成本，以及4段路程的经济成本。第二种乘车方案，应用于线上购票的场景：当乘客需要从城市A至城市B时，用户为了确保自己的出行得到保障，需要提前至线上按照出行日期，进行线上车票的购买。在出行日期当日乘客先从出发点自行前往城市A车站。同样地，为避免自己因为路上堵车等异常导致未能赶上车辆，乘客需要提前一定的时间前往车站。上车后通过长途客运到达城市B车站，再通过城市B车站枢纽到达目的地。对于该乘车方案来说，除去从城市A车站到城市B车站之间的路程之外，乘客还需要完成一段从出发点去往出发地汽车站的路程，一段从目的地汽车站至目的地的路程。共计多出2段的路程，那么也就多出2段路程的时间成本，多出2段路程的经济成本。另外，当前的城际客运为定点定时发车，乘客为了避免错过客运班车，会提前至客运站，这样又多出一段等待时间成本。可见，路线固定的轨道交通方式不能满足用户的个性化的行程中节约经济成本和时间成本的需求，而有限的社会交通资源限制了每个用户都可以保有车辆以实现个性化行程的可能性。针对上述问题，本发明实施例提供一种乘车服务处理方法，以解决轨道交通支持城际乘车方案中乘客等待时间长、换乘多且经济成本高的问题，能够使得官方城际营运达到门对门的服务水平，降低乘客出行的时间成本和经济成本，并且还能够根据相同行程来对乘车订单进行整合从而确定目标路线，进一步提高了多用户出行场景中的车辆利用率。下面说明实现本申请实施例的乘车服务处理设备的示例性应用，本申请实施例提供的乘车服务处理设备可以实施为服务器。下面，将说明乘车服务处理设备实施为服务器时涵盖服务器的示例性应用。参见图1，图1为本申请实施例乘车服务处理方法的网络架构示意图，为实现支撑一个示例性应用，乘客终端400示例性示出了乘客终端400-1和乘客终端400-2和司机终端100分别通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线链路实现数据传输。为了显示乘客终端400与司机终端100的区别，在图1中示例性地将司机终端100示为搭载在车辆中的终端。在司机终端100和乘客终端400中均可以按照有网络约车的应用程序Application，App，其中司机终端100中安装的可以是司机版App，司机可以通过该App接收服务器200发送的订单，查看订单信息等。乘客终端400中安装的可以是乘客版App，乘客可以通过该App发送订单给服务器200，以使得服务器200对乘客的订单派发给司机终端100，并且由服务器200向乘客终端400返回指派的车辆信息、司机信息。如果乘客选择的拼车服务的话，服务器200在接收到多个乘车订单之后，还需要根据乘车订单的上车地点、下车地点和乘车时间将不同的乘车订单进行合并，然后再将合并订单后的路线发送给司机终端100和乘客终端400。服务器200可以是单个的服务器，也可以是由多各服务器构成的服务器集群、云计算中心等，根据图2示出的服务器200的示例性结构，可以预见服务器200的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。图2所示的服务器200包括：至少一个处理器210、存储器240、至少一个网络接口220和用户接口230。终端200中的每个组件通过总线系统250耦合在一起。可理解，总线系统250用于实现这些组件之间的连接通信。总线系统250除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统250。用户接口230可以包括显示器、键盘、鼠标、触感板和触摸屏等。存储器240可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器ROM，ReadOnlyMemory。易失性存储器可以是随机存取存储器RAM，RandomAccessMemory。本申请实施例描述的存储器240旨在包括任意适合类型的存储器。本申请实施例中的存储器240能够存储数据以支持服务器200的操作。这些数据的示例包括：用于在服务器200上操作的任何计算机程序，如操作系统和应用程序。其中，操作系统包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务。应用程序可以包含各种应用程序。作为本申请实施例提供的乘车服务处理装置采用软件实施的示例，本申请实施例所提供的乘车服务处理装置可以直接体现为由处理器210执行的软件模块组合，软件模块可以位于存储介质中，存储介质位于存储器240，处理器210读取存储器240中软件模块包括的可执行指令，结合必要的硬件例如，包括处理器210以及连接到总线250的其他组件完成本申请实施例提供的方法。作为示例，处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器DSP，DigitalSignalProcessor，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。将结合前述的实现本申请实施例的乘车服务设备的示例性应用和实施，说明实现本申请实施例提供的乘车服务处理方法。参见图3，图3是本申请实施例提供的乘车服务处理方法的一个实现流程示意图，可以应用于图1所示的服务器200，根据乘车服务在终端400中实现方式，服务器200有各种差异性的部署方式。例如，当乘车服务在终端400中是以专用的乘车服务APP的形式实现时，服务器200可以是专门用于实现本发明实施例提供的乘车服务处理方法的一个或多个服务器，其通过网络300直接与乘车服务200通信以完成必要的数据和信息的传输。再例如，当乘车服务是在终端400中是以耦合到各种已有APP例如地图APP，社交APP中的模块或插件例如小程序实现时，服务器200可以包括用于实现这些已有APP的基本业务功能的业务服务器、以及用于实现本发明实施例提供的乘车服务处理方法的乘车服务器，乘车服务器直接与模块或插件通信，也可以间接通过业务服务器与模块或插件通信；当然，可以理解地，乘车服务器和业务服务器的区别主要在于所承载业务逻辑，因此，乘车服务器和业务服务器实际上也可以是同一服务器。在下文的描述中，为了描述方便，将上述各种可能方式的服务器都统称为服务器，因此服务器200不应简单理解为一个或一类服务器，而是根据上述的示例，在实际应用中为了支撑乘车服务而部署的各种可能形式的服务器，将结合图3示出的步骤进行说明。步骤S101，接收多个乘车订单。这里，乘车订单中至少包括上车地点、下车地点、乘车人数和乘车时间。在一些实施例中，乘车订单中还可以包括乘车人中是否有孕妇、老人或者小孩等信息。在本申请实施例中，乘车订单中的上车地点与下车地点一般为不同城市中的站点，也就是说乘车订单可以是城际之间的乘车订单。由于城际之间的乘车订单，往往路程比较远，乘车费用也相对较高，如果乘客在出行前临时取消订单，但此时可能司机已经在接驾的路程中，那么会给司机带来时间和金钱上的损失。因此该步骤接收到的乘车订单可以是已经支付成功的乘车订单。服务器接收到的多个乘车订单通常是通过多个乘客终端发送的，当然，在一些实施例中，也可以是使用同一乘客终端分别登录多个用户账号发送多个乘车订单。在一些实施例中，乘车订单中还可以包括该乘车订单对应的联系人和联系方式，以方便司机能够联系到乘客。步骤S102，确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合。这里，步骤S102在实现时，可以是：首先获取每个乘车订单中的上车地点、下车地点和乘车时间；然后确定每个乘车订单中上车地点所属的上车区域和下车地点所属的下车区域，最后确定满足以下条件的乘车订单，以形成相同行程订单集合：上车地点所属的上车区域相同、下车地点所属的下车区域相同、且乘车时间属于同一服务时间范围。确定上车地点所属的上车区域，可以是确定上车地点中预设行政级别对应的行政区。例如上车地点为广东省深圳市南山区深南大道123号，如果预设行政区级别为市级，那么上车地点所属的上车区域为深圳市，如果预设行政区级别为区县级，那么上车地点所属的上车区域为南山区。在本申请实施例中，预设行政级别可以为市级，因此本申请实施例提供的乘车服务处理方法，可以理解为是针对城际乘车服务。服务器会预先为提供城际乘车服务的时间范围进行设定。服务时间范围指的是，在该时间段内有车辆从线路的出发地出发，乘客可以在服务时间范围内选择不同的乘车区域上车。例如，一天中的服务时间范围为9点至10点，11点至12点，13点至14点，15点至16点，17点到18点。例如，乘客A的乘车订单为上午9：10从深圳市南山区出发到广州市白云区，乘客B的乘车订单为9：40从深圳市宝安区出发到广州市天河区。预设的行政区级别为市级。那么乘客A的上车地点所属的上车区域为深圳市，下车地点所属的下车区域为广州市，乘车时间为9：10。乘客B的上车地点所属的上车区域为深圳市，下车地点所属的下车区域为广州市，乘车时间为9：40。于乘客A的乘车订单和乘客B的乘车订单中上车地点所属的上车区域相同、下车地点所属的下车区域相同、且乘车时间属于同一服务时间范围，因此，这两个乘车订单可以认为市具有相同行程的订单。步骤S103，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线。这里，步骤S103在实现时，需要从相同行程订单集合中，在待调度车辆搭载不同数量的乘客的情况下，获取相应的订单，并通过这些订单确定待调度车辆对应的候选路线。候选路线中至少包括选择出的订单中的上车地点和下车地点。当选择出两个乘车订单时，到达两个乘车订单的上车地点的顺序不同，或到达两个乘车订单中下车地点的顺序不同，对应有不同的候选路线。假设第一乘车订单中的上车地点为S1、下车地点为D1，第二乘车订单中的上车地点为S2，下车地点为D2，那么候选路线可以是S1-S2-D1-D2，还可以是S1-S2-D2-D1、S2-S1-D1-D2、S2-S1-D2-D1。步骤S104，从所述候选路线中确定目标路线。这里，步骤S104在实现时，可以是基于路线决策的影响因素，从所述候选路线中确定目标路线，进一步地，可以是先确定出候选路线的各个影响因素，并基于各个影响因素对应的权重，确定出候选路线的决策值，再基于各个候选路线的决策值从多个候选路线中确定出目标路线。其中，路线决策的影响因素可以包括乘客数量、候选路线的里程总数、总时长、接送乘客的里程数和接送乘客的时长。在一些实施例中，还可以是基于其他方式从候选路线中确定目标路线，本申请实施例不做限定。步骤S105，将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。这里，可以通过以下方式实现如上述步骤中的S105：步骤S1051，基于所述目标路线对应的乘车订单、所述乘车订单的接送顺序，确定所述待调度车辆到达每个乘车订单的乘车地点的时间范围；步骤S1052，将所述目标路线对应的乘车订单、所述乘车订单的接送顺序和时间范围发送给所述待调度车辆。在一些实施例中，还可以将目标路线对应的乘车订单、所述乘车订单的接送顺序和时间范围发送给乘客终端，以使得乘客能够及时了解自己的预计乘车时间以及同行乘客的乘坐信息。在利用本申请实施例提供的方法为乘客提供乘车服务时，服务器在接收到多个乘车订单之后，首先根据乘车订单中携带的信息确定出具有相同行程的订单，并且在确定候选路线时，是基于待调度车辆的载客量和具有相同行程的订单确定的，进而再基于路线决策的影响因素确定目标路线；这样不仅能够保证待调度车辆的载客量能够满足候选路线中对应的乘车人数，并且还能保证派发给待调度车辆的订单是属于相同行程的最佳组合，从而能够使得车辆以最佳行程接送乘客，进一步缩短乘客的出行时间并降低出行成本。在一些实施例中，可以通过这样的方式来实现上述的步骤S103：步骤S1031，在不超出所述待调度车辆的载客量的情况下，确定所述待调度车辆的候选载客量。这里，待调度车辆的候选载客量可以是不大于该待调度车辆的载客量的正整数。例如当待调度车辆的载客量为3时，候选载客量可以为3个、2个和1个。在一些实施例中，司机还可以根据自身的实际情况设定候选载客量，例如司机不想绕路接多个乘客，可以将候选载客量设置为1个或两个，或者司机想尽可能多的载客，那么可以将候选载客量设置为3个。步骤S1032，从所述相同行程订单集合中分别确定对应每个候选载客量的乘车订单，以形成与每个候选载客量对应的候选乘车订单集合。这里，步骤S1032在实现时需要根据相同行程订单集合中每个乘车订单的乘车人数，来确定对应每个候选载客量的乘车订单。例如，当候选载客量为1个时，那么需要从相同行程订单集合中，确定出乘车人数为一个人的订单，作为候选载客量为1个的候选乘车订单。当候选载客量为2个时，需要从相同行程订单集合中分别选出两个乘车人数都为1个人的乘车订单，或者每次选出一个乘车人数为2个人的乘车订单作为候选乘车订单。假设相同行程订单集合中有五个乘车订单：订单1乘车人数1人、订单2乘车人数1人、订单3乘车人数2人、订单4乘车人数3人、订单5乘车人数2人。候选载客量分别为1个、2个和3个。那么候选载客量为1个对应的候选乘客订单集合为{订单1，订单2}，候选载客量为2个对应的候选乘客订单集合为{{订单1，订单2}、订单3，订单5}，候选载客量为3个对应的候选乘客订单集合为{{订单1，订单3}，{订单1，订单5}，{订单2，订单3}，{订单2，订单5}，订单4}。步骤S1033，根据所述每个候选乘车订单集合中各个乘车订单的上车地点和下车地点，确定包括所述上车地点和所述下车地点的候选路线。这里，假设订单1中上车地点为S1，下车地点为D1，订单2中上车地点为S2，下车地点为D2，那么候选订单集合中，{订单1，订单2}对应有四条候选路线，分别为：S1-S2-D1-D2、S1-S2-D2-D1、S2-S1-D1-D2、S2-S1-D2-D1。通过执行步骤S1031至步骤S1033，就能够根据待调度车辆的载客量，确定出待调度车辆搭载不同数量的乘客时，对应的候选订单集合，并且遍历出不同的候选订单集合对应的候选路线，能够保证遍历不同的乘车情况，以从确保在利用候选路线确定目标路线时的数据完备性。在一些实施例中，在一些实施例中，参见图4，图4为本申请实施例确定目标路线的实现流程示意图，图3示出的步骤S104可以通过如图4所示的步骤S1041至步骤S1045实现，以下将结合各步骤进行说明。步骤S1041，基于所述候选路线对应的乘车订单和所述乘车订单对应的接送顺序，确定所述候选路线的影响因素。这里，步骤S1041在实现时，可以是：基于所述候选路线对应的候选乘车订单和接送顺序，确定所述候选路线对应以下至少之一的影响因素：乘客数量、所述候选路线的里程数、完成所述候选路线的时长、接送乘客的里程数和接送乘客的时长。步骤S1042，获取每个候选路线对应的乘客数量和发车时间。这里，可以根据候选路线中所包含的各个乘车订单中的乘车人数，确定候选路线对应的乘客数量。候选路线的发车时间可以是第一个乘车订单对应的乘车时间，还可以是待调度车辆到达第一个上车地点的时间。步骤S1043，基于所述乘客数量确定所述候选路线对应的人数权重，并基于所述发车时间确定所述候选路线对应的时间权重。这里，不同的乘客数量对应有不同的人数权重，此时需要根据候选路线的乘客数量确定对应的人数权重。另外，不同的发车时间对应有不同的时间权重。在实现时，可以预先设置好一天中不同时间段对应的时间权重，例如在7:00至9:00，由于此时处于上班高峰期，交通比较拥堵，这一时间段对应的时间权重就比较高，而在11:00至12:00，交通比较顺畅，那么这一时间段对应的时间权重就比较低。步骤S1044，基于每个影响因素对应的权重，将每个影响因素进行加权，得到所述候选路线的决策值。这里，步骤S1044在实现时，首先要获取每个影响因素对应的权重。在本实施例中，每个影响因素对应的权重可以是预先设置好的。然后再将每个影响因素对应的权重和每个影响因素进行加权求和，以得到所述候选路线的决策值。在一些实施例中，还可以有待调度车辆的司机根据实际情况调整其中部分影响因素的权重，例如，司机比较注重行程的里程数，而不在意时间时，那么可以将行程里程数对应的权重调高，将接送时长、行程总时长对应的权重调低。步骤S1045，将决策值满足决策值取值条件的候选路线中确定目标路线。这里，决策值取值条件可以是决策值最小。在确定出各个候选路线的决策值之后，可以对各个候选路线的决策值进行排序，并将决策值最小的候选路线确定为目标路线，这样就能够确定出最优行程路线，以便待调度车辆按照该最优行程路线接送乘客，不仅能保证待调度车辆具有较低的运输成本，还能够使得乘客在设定的上车地点即可乘车，减少了等待时间和出行成本。在一些实施例中，在从所述候选路线中确定目标路线之后，或者在将所述目标路线发送给所述待调度车辆之后，还可以执行以下步骤：步骤21，获取对所述目标路线的调整信息。在本申请实施例中，在从候选路线中确定出目标路线之后，并且在将目标路线发送给待调度车辆之前，可以人为对目标路线进行核查，以进一步确定目标路线是否为最优路线，如果目标路线中有接送顺序不合理、或者目标路线中对应的订单不合理时，可以认为对目标路线进行调整，例如可以对接送顺序调整，还可以对所包括的订单进行调整。另外，在将目标路线发送给待调度车辆之后，司机也可以对目标路线进行调整，但司机对目标路线的调整仅限于对接送顺序的调整，并且司机调整之后，还需要发送给服务器进行审核，以确定司机的调整是否合理，以免司机随意调整接送顺序，给乘客带来不好的乘车体验。步骤22，基于所述调整信息，对路线决策的影响因素的权重进行调整。这里，服务器可以根据获取到的调整信息，利用机器学习、深度学习等不同的方式，对各个影响路线决策的影响因素的权值进行调整，从而能够提高后续确定目标路线的准确性和合理性。在一些实施例中，在步骤S105之后，还可以执行以下步骤：步骤S106，在所述待调度车辆的接单截止时间之前接收新乘车订单。这里，由于本申请实施例提供的是城际乘车服务，那么，待调度车辆在驶出出发城市之后，则不再进行接单了。因此，待调度车辆的接单截止时间可以是根据待调度车辆根据目标路线行驶时驶出出发城市的时间确定的，例如接单截止时间可以是待调度车辆根据目标路线行驶时驶出出发城市的时间之前半个小时。假设待调度车辆驶出出发城市的时间为10点，那么接单截止时间可以是9:30。步骤S107，当所述目标路线对应的乘客数量小于所述待调度车辆的载客量时，从所述新乘客订单中确定目标乘客订单。这里，如果目标路线对应的乘客数量小于所述待调度车辆的载客量，说明此时待调度车辆可以再接乘车订单，以搭载更多的乘客，因此可以确定满足以下条件的新乘车订单为目标乘车订单：所述待调度车辆到达所述新乘车订单对应的上车地点的时间，与所述新乘车订单对应的乘车时间的时间差小于时间差阈值；所述新乘车订单与所述待调度车辆的已分配乘车订单的乘客数量小于或等于所述待调度车辆的载客量。另外还需要保证增加目标乘客订单之后，不会对目标路线中其他订单的上车时间带来很大的影响。步骤S108，基于所述目标乘车订单对所述目标路线进行更新，得到新目标路线。这里，需要根据目标乘车订单的上车地点，对目标路线进行更新，以保证新目标路线中包括目标乘车订单的上车地点。步骤S109，将所述新目标路线发送给所述待调度车辆以替换原始的所述目标路线。在一些实施例中，还需要将新目标路线发送给各个乘车订单对应的乘客终端，以便乘客能够对行程的变更及时了解。通过实施步骤S106至步骤S109，能够使得当待调度车辆还可以在行程中接单时，在到达接单截止时间之前，从获取到的新乘车订单中，确定出目标乘客订单，并基于目标乘车订单对目标路线进行更新，得到新目标路线，这样能够再不影响已接乘客行程的基础上，使得待调度车辆能够多搭载乘客，从而提高运营收益。本申请实施例提供一种乘车服务处理方法，应用于乘车服务系统，该乘车服务系统至少包括乘客终端、服务器和待调度车辆。图5为本申请实施例乘车服务处理方法的又一个实现流程示意图，如图5所示，所述方法包括：步骤S301，乘客终端获取乘车的上车地点、下车地点和乘车时间。这里，乘客终端获取乘车的上车地点、下车地点和乘车时间的方式可以是通过乘客输入的文本信息获取，还可以是通过乘客点击网络地图的位置信息获取，还可以通过拾取乘客的语音并进行语音识别获取。在本申请实施例中，乘客订单中的上车地点和下车地点可以是属于不同城市的地点。步骤S302，乘客终端根据所述上车地点、下车地点和乘车时间生成乘车订单。步骤S303，乘客终端发送所述乘车订单到服务器。步骤S304，服务器接收到乘客终端发送的乘车订单后，判断乘车订单是否超出服务能力。这里，如果确定乘车订单超出服务能力，进入步骤S305；如果确定乘车订单未超出服务能力，进入步骤S309。在本申请实施例中，服务能力可以是预先设置的服务地点范围和服务时间范围。判断乘车订单是否超出服务能力，可以是判断上车地点是否在服务地点范围内，判断下车地点是否在服务地点范围内，乘车时间是否在服务时间范围内，当上车地点在服务地点范围内，且下车地点在服务地点范围内，且乘车时间在服务时间范围内时，认为乘车订单未超出服务能力，这三者中若至少有一个不在服务范围内，则表明乘车订单超出服务能力。在一些实施例中，步骤S304中服务器接收到的是乘车订单是要增加至已确定的目标路线中的新乘车订单时，服务能力还可以是，在保证待调度车辆能够准时执行原始的目标路线以接送相乘车订单的乘客的基础上，待调度车辆完成新乘车订单时所能到达的上下车地点的范围、和所能搭载的乘车人数的最大值。步骤S305，服务器基于符合所述服务能力的服务时间范围和服务地点范围确定推荐信息。这里，如果上车地点不在服务地点范围内，则服务器基于乘车订单中的上车地点从服务地点范围内确定出推荐上车地点。推荐上车地点可以是离乘车订单中上车地点最近的站点，还可以是从乘车订单中的上车地点出发出行最方便的站点。如果下车地点不在服务地点范围内，则服务器基于乘车订单中的下车地点从服务地点范围内确定出推荐下车地点。如果乘车时间不在服务时间范围内，则根据乘车时间确定出推荐乘车时间。推荐信息中包括推荐上车地点、推荐下车地点和推荐乘车时间中的至少之一。步骤S306，服务器将所述推荐信息发送给乘客终端。步骤S307，乘客终端在接收到推荐信息后，基于推荐信息调整乘车订单，得到调整后的乘车订单。这里，乘客终端在接收到推荐信息后，如果乘客认为推荐信息可以接受，那么基于推荐信息调整乘车订单；如果乘客认为推荐信息不能接受，那么结束流程。步骤S308，乘客终端将调整后的乘车订单发送给服务器。步骤S309，服务器基于所述乘车订单对应的上车地点、下车地点和乘客数量确定乘车费用。如果是从步骤S304之后进入到步骤之后进入到步骤309时，那么步骤S309中的乘客订单即为步骤S302中生成的乘车订单；如果是从步骤S308之后进入到步骤309时，那么步骤S309中的乘客订单即为步骤S308中得到的调整后的乘车订单。步骤S310，服务器基于所述乘车费用向所述客户端发起支付请求，以使所述客户端完成支付。这里，支付请求中至少包括有乘车费用。步骤S311，乘客终端基于支付请求对乘车订单进行支付。步骤S312，乘客终端将支付完成的乘车订单发送给服务器。步骤S313，服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合。这里，服务器接收到的多个乘车订单可以是已支付成功的乘车订单。步骤S314，服务器基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，步骤S315，服务器根据路线决策的影响因素，从所述候选路线中确定目标路线。步骤S316，服务器将目标路线发送给待调度车辆和乘客终端。步骤S317，服务器在乘客终端和待调度车辆之间同步目标路线的完成进度信息。这里，当在行程中，待调度车辆接到一个乘车订单对应的乘客后，可以在司机终端中确认已接到乘客，并将确认信息发送给服务器，服务器会将该确认信息同步到目标路线中各个乘车订单对应的乘客终端中，已使得同行乘客了解当前行程的进度。需要说明的是，本实施例中与其它实施例中相同步骤或概念的解释可以参考其它实施例中的描述。在本申请实施例提供的乘车服务处理方法中，乘客可以自行根据出行需求设置行程的上车地点、下车地点和乘车时间，这样就省去了乘客因为往返车站所产生的时间成本和经济成本，并且服务器会对乘客设置的上下车站点和乘车时间进行确认，保证乘客最终下发的乘客订单中的上下车地点和乘车时间在服务范围内，以避免耽误乘客出行。另外，服务器还会根据相同行程来对乘车订单进行整合从而确定目标路线，进一步提高了多用户出行场景中的车辆利用率。下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。本申请实施例提供一种乘车服务处理方法，图6A为本申请实施例乘车服务处理方法的再一个实现流程示意图，如图6A所示，所述方法包括：步骤S601，乘客端输入用车时间。这里，本实施例中的乘客端对应其他实施例中的乘客客户端或乘客终端。乘客可以通过终端上安装的网络约车App的客户端，输入用车时间，还可以通过网页进入网络约车界面或者其他应用中关联的网络约车小程序，输入用车时间。用车时间对应其他实施中的乘车时间，也可以称为预计上车时间或者计划上车时间。步骤S602，乘客端输入上下站点。这里，乘客还可以进一步输入上车站点和下车站点。在本实施例中，上车站点和下车站点可以是属于不同城市的站点。需要说明的是，在本申请实施例中并不限定步骤S601和步骤S602的执行顺序，在一些实施例中，还可以先执行步骤S602，即先输入上下站点，再执行步骤S601，也即再输入用车时间。当然，还可以是先输入上车站点，再输入用车时间，最后再输入下车站点。步骤S603，判断上下站点是否在服务覆盖范围之内。这里，如果上车站点和下车站点都在服务覆盖范围之内，则进入步骤S604，如果上车站点或下车站点不在服务覆盖范围之内，进入步骤S605。步骤S604，乘客端确定人数及联系人。这里，在确定上车站点和下车站点都在服务范围之内之后，乘客可以进一步选择乘车人数，以及乘车订单的联系人。在本申请实施例中，确定联系人可以进一步是确定乘车人的联系方式。乘车人可以是下发乘车订单的终端对应的用户，还可以是其他用户。也就是说，用户可以为自己进行网络约车，还可以为其他人进行网络约车。步骤S605，服务器端推荐上下站点。这里，当上车站点或下车站点不在服务覆盖范围内时，服务器会根据乘客输入的上车站点或下车站点，推荐在服务覆盖范围内的就近站点。步骤S606，乘客端判断是否接受推荐服务。这里，乘客端在接收到服务器发送的推荐上车站点或下车站点之后，可以由乘客决定是否接受推荐服务。如果接受推荐服务，此时进入步骤S609；如果不接受推荐服务，结束流程。步骤S607，服务器端进行线路设定。这里，服务器端根据对用户出行的行程的统计分析，进行线路设定。步骤S608，服务器端设定服务时间和服务范围。这里，服务器端可以根据设定好的线路所经过的站点确定服务范围，可以根据完成各个线路所需的时间设定服务时间。步骤S609，乘客端向服务器发送价格查询请求。这里，在乘客端选定好上车站点、下车站点和用车时间之后，可以向服务器发送价格查询请求，以获取乘车费用。价格查询请求中可以携带有上车站点、下车站点和用车时间。步骤S610，服务器端基于价格查询请求进行价格查询。这里，服务器在接收到乘客端的价格请求之后，结合上车站点、下车站点和用车时间按照预定的算法，计算该乘车订单对应的价格。步骤S611，服务器端向乘客端反馈价格。步骤S612，如果乘客端接受价格，支付订单。这里，乘客端接收到服务器返回的价格后，乘客会根据该价格确定是否进行支付。例如，乘客在早高峰出行时，可能对于相对于平峰时段出行即便时相同的上车站点和下车站点，价格要高出很多，那么如果乘客并不是有急事，则可以不接受该价格，而选择其他时间段出行。而如果乘客认为价格可以接受，那么可以进行订单的支付过程。步骤S613，乘客端将支付完成的订单发送给服务器端，以使得服务器端对所有行程进行撮合。这里，服务器端是对已经支付过的行程进行撮合。对行程进行撮合可以是将上车站点为同一城市，且下车站点为同一城市，且用车时间在发车时间范围内的行程根据待调度车辆的座位数进行合并，也即进行拼单。步骤S614，服务器端在撮合成功后，将发车订单推送给司机端。这里，服务器端在将行程撮合成功后，将撮合得到的发车订单发送给对应车辆的司机，发车订单可以包括多个乘车订单，以及这多个乘车订单的接送顺序。司机端对应其他实施例中的司机终端或者司机客户端。步骤S615，司机端接受订单。这里，服务器端在将发车订单发送给司机端之后，司机端可以根据当前的车辆情况选择接受或者不接受订单。例如当车辆距离发车订单距离较远时，司机端可以不接受订单。步骤S616，服务器端将车辆信息和司机信息发送给乘客端。步骤S617，司机端接上任意乘客后进行接上乘客的确认操作。这里，司机在接到乘客之后，可以在司机端确认已接上该乘客的操作，司机端还可以在接收到确认操作后，将确认已接上该乘客的信息发送给服务器端，服务器端将已接上该乘客的信息同步到发车订单中各个乘客订单对应的乘客端。步骤S618，乘客端在到达目的地后，结束。这里，乘客在到达目的地后，可以在乘客端进行确认到达目的地的操作，此时乘客端对应的乘车订单完成。对于司机端来说，在发车订单中的各个乘客都确认到达目的地后，该发车订单完成。图6B至图6I为本申请实施例提供的乘车服务处理方法在乘客端的实现过程的界面示意图，下面结合图6B至6I对本申请实施例提供的乘车服务方法的实现过程进行说明。图6B为本申请实施例乘客端选择用车时间的界面示意图，如图6B所示，用户可以在611所示的图形控件中选择用车的日期，以及具体的时间。图6C为本申请实施例乘客输入上下车站点的界面示意图，如图6C所示，上车站点可以默认是乘客的当前位置，用户可以点击图6C中输入控件621对应的屏幕位置，以输入下车站点。此时会显示如图6D所示的城市选择界面，用户可以查看有哪些城市开通了该乘车服务，以便确认自身的下车地点是否在开通城市之内。假设乘客下车地点所在的城市为广州631，那么在乘客选择了广州631之后，会显示如图6E所示的界面，乘客可以在该界面中通过输入控件641输入具体的下车地点。完成预约用车时间、上车点和下车点后，则会输出显然如图6F所示的行程确认界面。参见图6F所示的行程确认界面中的651，此处默认为1人乘车且愿意拼车，乘客根据自我意愿将调整为包车或者多人乘车的需求。同时在图6F中的652所在区域显示乘车订单的联系方式。一般默认注册手机号码为乘车人的联系号码，乘客也可以更改联系方式或者为他人代购车票。当乘客对行程确认无误后，可以点击“确认用车”的按钮控件，以进行乘车费用的支付，在支付完成后也即完成车票购买。图6G为本申请实施例的支付界面示意图，如图6G所示，用户可以点击支付控件661，以完成支付。图6H为本申请实施例显示行程信息的界面示意图，在支付完成后会在显示界面中显示如图6H所示的行程信息，例如会在区域671中显示司机信息、服务公司信息及车辆信息，在区域672中显示同行人数情况，在区域673中显示行程路径、发车时间、乘车人数等信息。服务器会根据已经支付的乘车订单进行订单撮合，以确定出车辆的行程路线，并将行程路线信息发送给司机和乘客。其中，服务器根据拼车的订单，确定接送顺序，并向乘客反馈接送顺序，以及到达乘客上车地点的时间、到达下车地点的时间等等。图6I为本申请实施例在行程中的界面示意图，如图6I所示，在区域681中显示司机信息、服务公司信息及车辆信息，在区域682中显示接送顺序及当前正在接送的乘客，在区域682中显示自己的行程路径、到达乘客上车地点的时间、到达下车地点的时间等等。乘客完成行程后，行程中变更成行程结束，此时会显示如图6J所示的界面，如图6J所示乘客可以查看具体的费用情况，时间，行程单。针对有发票需求的用户也可以开具发票，有回程需求用户可以直接进行购票，同时可以通过691所示的显示区域对于该次乘车服务进行评价。在本申请实施例中，根据服务器所实现的不同的业务逻辑，还可以进一步包括：线路系统、订单系统、排版系统和线路撮合系统。图7为本申请实施例乘客订单处理的实现时序示意图，如图7所示，该实现过程包括：步骤S701，用户执行打开小程序的操作。这里，小程序是可以运行在已安装的应用程序中的网页程序，也就是说，小程序是一种不用下载就能使用的应用程序。步骤S701中的小程序可以是安装在支付应用、地图应用或即时通讯应用中能够进行网络约车的网页程序。需要说明的是，本实施例中以在小程序中进行网络约车仅为示例性的。在一些实施例中，还可以以小程序之外的其他方式进行网络约车，例如可以通过进入网络约车的网页，或者通过终端中安装的网络约车App。步骤S702，基于用户的打开操作进入小程序。步骤S703，在小程序中选择预约用车时间。这里，在实现时，可以是用户在小程序中执行了选择预约用车时间的操作。步骤S704，小程序向线路系统请求可服务时间。这里，在用户执行了获取选择预约用车时间的操作后，小程序向线路系统发送获取预约用车时间的请求。在获取预约用车时间的请求中，可以携带有乘客的位置信息。步骤S705，线路系统查询对应城市的服务时间。这里，线路系统基于乘客的位置信息查询对应城市的服务时间。步骤S706，线路系统向小程序返回可服务时间。这里，在接收到线路系统返回的可服务时间之后，在小程序的界面中输出显示可服务时间，以供用户选择用车时间。步骤S707，用户输入上下车站点。这里，可以是用户在小程序所提供的输入控件中输入上车站点和下车站点，还可以是用户点击小程序中显示的地图，然后基于用户的点击位置和地图的显示信息确定上车站点或下车站点。在一些实施例中，用户还可以是通过语音的方式输入上车站点和下车站点。以上所列举出的输入上下车站点的方式仅仅为示例性的，本领域技术人员利用本申请的技术思想，根据其具体需求所提出的其它输入上下车站点的方式均在本申请的保护范围内，在此不进行一一穷举。步骤S708，小程序向线路系统请求查询上下车站点是否在服务范围内。这里，小程序将携带有上车站点和下车站点的查询请求发送给线路系统，以确定上车站点和下车站点是否在服务范围内。步骤S709，线路系统基于接收到的查询请求，查询上下车站点是否在服务范围内。这里，线路系统在接收到查询请求后，获取查询请求中携带的上车站点和下车站点，然后通过查询自身存储的服务站点数据库，判断服务站点数据库中是否存在与查询请求中的上车站点和下车站点匹配的站点。如果服务站点数据库中存在与查询请求中的上车站点和下车站点匹配的站点，那么进入步骤S710；如果服务站点数据库中不存在与查询请求中的上车站点和下车站点匹配的站点，那么，线路系统可以向小程序返回推荐的上车站点和下车站点。步骤S710，线路系统确定上下车站点在服务范围内。步骤S711，线路系统向小程序返回地址可用，以及返回行程价格。这里，如果用户输入的上下车站点在服务范围内，线路系统会根据上车站点与下车站点之间的距离，计算行程价格，并将行程价格发送给小程序。需要说明的是，在该步骤中，线路系统返回的行程价格是一个参考价格，并不一定是最终的行车价格，因为最终的行程价格还需要根据乘车人数、用车时间进行计算。步骤S712，小程序进入行程确认页。步骤S713，用户调整人数、联系人。这里，用户还可以根据实际出行需求，对乘车人数或者与司机进行联系的联系人进行调整。步骤S714，小程序向线路系统请求调整人数后的行程价格。如果用户对乘车人数进行了调整，那么小程序需要向线路系统再次请求调整人数后的行程价格。步骤S715，线路系统根据距离、人数确定价格。步骤S716，线路系统向小程序返回价格。步骤S717，小程序在显示界面输出显示行程价格。小程序在接收到线路系统发送的行程价格后，会输出该行程价格，以使得用户确认是否接受该价格。在输出行程价格的界面中，还可以提供有支付控件，如果用户能够接受最终的行程价格，进入步骤S718。步骤S718，用户进行支付行程费用的操作。用户通过小程序提供的支付控件进行在线支付操作。步骤S719，小程序向订单系统发送支付订单请求。步骤S720，订单系统基于接收到的支付订单请求进行订单创建，支付处理。这里，订单系统在完成订单创建之后，为用户提供不同的支付方式，例如可以通过网银支付、还可以利用专门的支付应用进行支付，也可以利用即时通讯应用中的支付组件进行支付。订单系统会基于用户选择的支付方式，将待支付订单信息发送给用户选择的支付方式对应的服务器，以根据待支付订单信息进行扣款。步骤S721，订单系统向排班系统发送订单支付成功的通知消息。这里，在扣款成功后，订单系统向排班系统发送订单支付成功的通知消息，以通知排班系统对该订单进行派车。步骤S722，排班系统查询对应线路排班。在本实施例中，排班系统在接收到支付成功的订单之后，根据订单的上下车站点和乘车时间，查询上下车站点对应的线路的排班情况，以确定有没有与该乘车时间相匹配的可调度车辆。步骤S723，排班系统向小程序反馈支付和派车情况。这里，如果排班系统确定上下车站点对应的线路排班中，有与该乘车时间相匹配的可调度车辆，那么排班系统向小程序反馈支付成功，以及所指派车辆的车辆信息和司机信息。步骤S724，在小程序中进入行程确认页面。步骤S725，小程序向用户显示购票成功。步骤S726，线路撮合系统基于已购票成功的订单进行线路撮合。步骤S727，线路撮合系统向小程序发送撮合完成的通知消息。这里，在撮合完成之后，线路撮合系统需要将撮合得到的发车订单发送给小程序，发车订单中可以包括一个或多个乘车订单，当发车订单中包括多个乘车订单时，发车订单中还包括多个乘车订单的接送顺序，达到各个乘车订单的上车站点的预计时间等。步骤S728，小程序反馈具体出行时间和接送次序。在本申请实施例中，步骤S726可以通过以下步骤实现：步骤S7261，获取乘客已购票成功的订单。这里，通过乘客已购票成功的订单，确定乘客的行程，也即确定乘客的出行线路和时间。步骤S7262，在到达行程的购票截止时间时，筛选出同一行程。在本实施例中，排班系统还可以为不同的乘车区域设定不同的发车时间。例如，对于从深圳到广州的线路，可调度车辆9点钟从出发城市深圳的罗湖出发，经过福田区、南山区和宝安区，进而再到达目的城市广州。其中，罗湖区的发车时间为9点钟，福田区的发车时间为9:20，南山区的发车时间为9:40，宝安区的发车时间为10:10。假设在每个乘车区域为乘客预留十分钟的时间，那么，罗湖区乘客的上车时间范围为9:00-9:10，福田区乘客的上车时间范围为9:20-9:30，南山区乘客的上车时间范围为9:40-9:50，宝安区乘客的上车时间范围是10:10-10:20。那么该车辆的发车总时间为9：00-10:10，购票截止时间可以是在最后的发车时间之前一段时间，例如可以是最后的发车时间前半个小时或者一个小时。同一行程可以认为是上车站点为同一城市、下车站点也在同一城市，且乘车时间在发车时间范围内的行程。例如，一个乘客的行程为9:00从深圳罗湖区到广州天河区，另一个乘客的行程为9:45从深圳南山区到广州番禹区，那么这两个乘客的行程的上车站点和下车站点均为同一城市，且乘车时间在发车时间范围内，此时可以认为是同一行程。在一些实施例中，还可以根据各个订单上车时间要求匹配如上的计算出各个乘车区域的时间范围，以确定各个乘车区域中上车时间满足对应时间范围的乘客数量，假设四个乘车区域对应匹配的上车人数为P1，P2，P3，P4，然后可以根据各个乘车区域匹配的上车人数进行订单撮合。步骤S7263，获取使用的车型对应座位数为W。W为不小于1的整数。步骤S7264，计算任意一个区域，任意x00需要整体行程公里数Lx，所需整体行程时间数Tx，接送所产生的行程公里数lx，接送所产生的行程时间数tx，整体行程所产生的运输成本Cx。步骤S7265，设置不同拼车人数影响因子Yx，整体行程公里数影响因子YL，整体行程时间影响因子YT，接送所产生的行程公里数影响因子Yl，接送所产生的行程时间数影响因子Yt，整体行程所产生的运输成本影响因子YC。本申请实施例中的影响因子对应其他实施中的权重。整体行程时间影响因子YT，与发车时间具有一定的关系。在实现过程中，可以利用公式2-1确定整体行程时间影响因子YT：YT＝YnT*n2-1；其中，n为影响因子系数n0，YnT为基础影响因子。n与发车时间有关，当发车时间在早晚高峰时段时，n的取值比发车时间在平峰时段时n的取值要大。步骤S7266，确定每条线路的决策值。在实现时，可以根据公式2-2确定每条线路的决策值Pm：Pm＝YxLx*YL+Tx*YT+lx*Yl+tx*Yt+Cx*YC2-2；步骤S7267，根据计算出了所有线路的决策值，找到完成所有乘客接送最终的方案组合的最优排列。最优解即为选定最终拼车人数，同行人，具体的接送区域对应接送人数P、接送顺序及接送时间。通过实施本申请实施例提供的乘车服务处理方法，能够将路程由五段或者三段服务提升为一段路程服务，从而能够消除乘客出发地目的地与汽车站之间运行的时间成本和经济成本，并且消除乘客无需在出发地汽车站等候，从而能够改善乘客耗时长、转乘多、费用高的糟糕体验。另外待调度车辆为经过官方营运公司授权的，因此使得官方营运能够达到门到门的服务水平，进一步变革长途客运的运作模式，减少车站的建设，加大车辆流动性，完成客运企业变革。性结构，在一些实施例中，如图2所示，乘车服务处理装下面继续说明如图2示出的乘车服务处理装置中软件模块的示例置80中的软件模块可以包括：第一接收模块81，用于接收多个乘车订单；第一确定模块82，用于确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；第二确定模块83，用于基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；第三确定模块84，用于从所述候选路线中确定目标路线；例如可以是基于路线决策的影响因素确定从所述候选路线中确定目标路线。第一发送模块85，用于将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。在一些实施例中，所述装置还进一步包括：第一获取模块，用于获取每个乘车订单中的上车地点、下车地点和乘车时间；所述第一确定模块，还用于确定满足以下条件的乘车订单，以形成相同行程订单集合：上车地点所属的上车区域相同、下车地点所属的下车区域相同、且乘车时间在服务时间范围内。在一些实施例中，第二确定模块，还用于在不超出所述待调度车辆的载客量的情况下，确定所述待调度车辆的候选载客量；从所述相同行程订单集合中分别确定对应每个候选载客量的乘车订单，以形成与每个候选载客量对应的候选乘车订单集合；根据所述每个候选乘车订单集合中各个乘车订单的上车地点和下车地点，确定包括所述上车地点和所述下车地点的候选路线。在一些实施例中，第三确定模块，还用于基于所述候选路线对应的乘车订单和所述乘车订单对应的接送顺序，确定所述候选路线的影响因素；基于每个影响因素对应的权重，将每个影响因素进行加权，得到所述候选路线的决策值；将决策值满足决策值取值条件的候选路线中确定目标路线。在一些实施例中，所述第三确定模块，还用于基于所述候选路线对应的候选乘车订单和接送顺序，确定所述候选路线对应以下至少之一的影响因素：乘客数量、所述相同行程的里程数、所述相同行程的时长、接送乘客的里程数和接送乘客的时长。在一些实施例中，所述装置还进一步包括：第二获取模块，用于获取每个候选路线对应的乘客数量和发车时间；所述第三确定模块，还用于基于所述乘客数量确定所述候选路线对应的人数权重，并基于所述发车时间确定所述候选路线对应的时间权重。在一些实施例中，所述第三确定模块，还用于基于所述目标路线对应的乘车订单、所述乘车订单的接送顺序，确定所述待调度车辆到达每个乘车订单的上车地点的时间范围；所述第一发送模块，还用于将所述目标路线对应的乘车订单、所述乘车订单的接送顺序和时间范围发送给所述待调度车辆。在一些实施例中，所述装置还进一步包括：在从所述候选路线中确定目标路线之后，或者在将所述目标路线发送给所述待调度车辆之后，第三获取模块，用于获取对所述目标路线的调整信息；调整模块，用于基于所述调整信息，对路线决策的影响因素的权重进行调整。在一些实施例中，所述接收模块还用于，在所述待调度车辆的接单截止时间之前接收新乘车订单；所述第三确定模块，还用于当所述目标路线对应的乘客数量小于所述待调度车辆的载客量时，确定满足以下条件的新乘车订单为目标乘车订单：所述待调度车辆到达所述新乘车订单对应的上车地点的时间，与所述新乘车订单对应的乘车时间的时间差小于时间差阈值；所述新乘车订单与所述待调度车辆的已分配乘车订单的乘客数量小于或等于所述待调度车辆的载客量；所述装置还包括：更新模块，用于基于所述目标乘车订单对原始的所述目标路线进行更新，得到新目标路线；所述第一发送模块，还用于将所述新目标路线发送给所述待调度车辆以替换原始的所述目标路线。在一些实施例中，所述第一确定模块，还用于当确定所述乘车订单未超出服务能力时，基于所述乘车订单对应的上车地点、下车地点和乘客人数确定乘车费用；所述装置还包括：支付发起模块，用于基于所述乘车费用向所述乘客终端发起支付请求，以使所述乘客终端完成支付。在一些实施例中，所述第一确定模块，还用于当所述乘车订单不符合服务要求时，基于所述乘车订单、服务时间范围和服务地点范围确定推荐信息，其中，所述推荐信息中包括推荐上车地点、推荐下车地点和推荐乘车时间至少之一；所述第一发送模块，还用于将所述推荐信息发送给所述乘客终端。本申请实施例再提供一种乘车服务处理装置，该乘车服务器处理装置可以为图1示出的乘客终端400。乘客终端400可以是移动电话手机、平板电脑、笔记本电脑等具有无线通信能力的移动终端，还可以是不便移动的具有通信能力的台式计算机、桌面电脑等。根据图8示出的乘客终端400的示例性结构，可以预见乘客终端400的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。图8所示的乘客终端400包括：至少一个处理器410、存储器440、至少一个网络接口420和用户接口430。处理器410、存储器440、至少一个网络接口420和用户接口430可以参照上文服务器200中所包括的处理器210、存储器240、至少一个网络接口220和用户接口230的说明而理解。下面说明位于存储器440中的乘车服务处理装置90的各个软件模块的示例性结构，在一些实施例中，如图8所示，乘车服务处理装置90中的软件模块可以包括：第四获取模块91，用于获取乘车的上车地点、下车地点和乘车时间；订单生成模块92，用于根据所述上车地点、下车地点和乘车时间生成乘车订单；第二发送模块93，用于发送所述乘车订单到服务器，以使所述服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，从所述候选路线中确定目标路线；第二接收模块94，用于接收所述服务器发送的目标路线。本申请实施例中提供的乘车服务处理装置，可以为图1中所示的终端。需要说明的是，上述乘车服务处理装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，例如，如图3至图7示出的方法。在一些实施例中，存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言包括编译或解释语言，或者声明性或过程性语言来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言HTML，HyperTextMarkupLanguage文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件例如，存储一个或多个模块、子程序或代码部分的文件中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

权利要求：1.一种乘车服务处理方法，其特征在于，所述方法包括：接收多个乘车订单；确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；从所述候选路线中确定目标路线；将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。2.根据权利要求1中所述的方法，其特征在于，所述确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合，包括：获取每个乘车订单中的上车地点、下车地点和乘车时间；确定满足以下条件的乘车订单，以形成相同行程订单集合：上车地点所属的上车区域相同；下车地点所属的下车区域相同；乘车时间在服务时间范围内。3.根据权利要求1中所述的方法，其特征在于，所述基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，包括：在不超出所述待调度车辆的载客量的情况下，确定所述待调度车辆的候选载客量；从所述相同行程订单集合中分别确定对应每个候选载客量的乘车订单，以形成与每个候选载客量对应的候选乘车订单集合；根据所述每个候选乘车订单集合中各个乘车订单的上车地点和下车地点，确定包括所述上车地点和所述下车地点的候选路线。4.根据权利要求1中所述的方法，其特征在于，从所述候选路线中确定目标路线，包括：基于所述候选路线对应的乘车订单和所述乘车订单对应的接送顺序，确定所述候选路线的影响因素；基于每个影响因素对应的权重将每个影响因素进行加权，得到所述候选路线的决策值；将决策值满足决策值取值条件的候选路线确定为目标路线。5.根据权利要求4中的方法，其特征在于，所述基于所述候选路线对应的乘车订单和和所述乘车订单对应的接送顺序，确定所述候选路线的影响因素，包括：基于所述候选路线对应的候选乘车订单和接送顺序，确定所述候选路线对应以下至少之一的影响因素：乘客数量；所述相同行程的里程数；所述相同行程的时长；接送乘客的里程数和接送乘客的时长。6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：获取每个候选路线对应的乘客数量和发车时间；基于所述乘客数量确定所述候选路线对应的人数权重，并基于所述发车时间确定所述候选路线对应的时间权重。7.根据权利要求1至5中所述的方法，其特征在于，所述将所述目标路线发送给所述待调度车辆，包括：基于所述目标路线对应的乘车订单、所述乘车订单的接送顺序，确定所述待调度车辆到达每个乘车订单的乘车地点的时间范围；将所述目标路线对应的乘车订单、所述乘车订单的接送顺序和时间范围发送给所述待调度车辆。8.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：在从所述候选路线中确定目标路线之后，或者在将所述目标路线发送给所述待调度车辆之后，获取对所述目标路线的调整信息；基于所述调整信息，对路线决策的影响因素的权重进行调整。9.根据权利要求1至5中所述的方法，其特征在于，所述方法还包括：在所述待调度车辆的接单截止时间之前接收新乘车订单；当所述目标路线对应的乘客数量小于所述待调度车辆的载客量时，确定满足以下条件的新乘车订单为目标乘车订单：所述待调度车辆到达所述新乘车订单对应的上车地点的时间，与所述新乘车订单对应的乘车时间的时间差小于时间差阈值；所述新乘车订单与所述待调度车辆的已分配乘车订单的乘客数量小于或等于所述待调度车辆的载客量；基于所述目标乘车订单对原始的所述目标路线进行更新，得到新目标路线；将所述新目标路线发送给所述待调度车辆以替换原始的所述目标路线。10.根据权利要求1至5中所述的方法，其特征在于，所述方法还包括：当确定所述乘车订单超出服务能力时，基于符合所述服务能力的服务时间范围和服务地点范围确定推荐信息，其中，所述推荐信息中包括推荐上车地点、推荐下车地点和推荐乘车时间至少之一；将所述推荐信息发送给所述乘客终端。11.一种乘车服务处理方法，其特征在于，所述方法包括：获取乘车的上车地点、下车地点和乘车时间；根据所述上车地点、下车地点和乘车时间生成乘车订单；发送所述乘车订单到服务器，以使所述服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，从所述候选路线中确定目标路线；接收所述服务器发送的目标路线。12.一种乘车服务处理装置，其特征在于，所述装置包括：第一接收模块，用于接收多个乘车订单；第一确定模块，用于确定所述多个乘车订单中具有相同行程的订单，以形成相同行程订单集合；第二确定模块，用于基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线；第三确定模块，用于从所述候选路线中确定目标路线；第一发送模块，用于将所述目标路线发送给所述待调度车辆，以使所述待调度车辆执行所述目标路线。13.一种乘车服务处理装置，其特征在于，所述装置包括：第四获取模块，用于获取乘车的上车地点、下车地点和乘车时间；订单生成模块，用于根据所述上车地点、下车地点和乘车时间生成乘车订单；第二发送模块，用于发送所述乘车订单到服务器，以使所述服务器从接收的多个乘车订单中确定具有相同行程的订单，以形成相同行程订单集合，基于待调度车辆的载客量和所述相同行程订单集合，确定所述待调度车辆对应的候选路线，从所述候选路线中确定目标路线；第二接收模块，用于接收所述服务器发送的目标路线。14.一种乘车服务处理设备，其特征在于，所述设备包括：存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至10或权利要求11任一项所述的方法。15.一种存储介质，其特征在于，存储有可执行指令，用于引起处理器执行时，实现权利要求1至10或权利要求11任一项所述的方法。

百度查询： 腾讯科技(深圳)有限公司 乘车服务处理方法、装置、设备及存储介质

免责声明
1、本报告根据公开、合法渠道获得相关数据和信息，力求客观、公正，但并不保证数据的最终完整性和准确性。
2、报告中的分析和结论仅反映本公司于发布本报告当日的职业理解，仅供参考使用，不能作为本公司承担任何法律责任的依据或者凭证。

阅读全文 双屏查看 官方信息 专利公告 收藏专利 下载PDF 下载WORD