CN113240477A - 订单派发方法、订单派发装置和可读存储介质 - Google Patents

订单派发方法、订单派发装置和可读存储介质 Download PDF

Info

Publication number
CN113240477A
CN113240477A CN202110686384.7A CN202110686384A CN113240477A CN 113240477 A CN113240477 A CN 113240477A CN 202110686384 A CN202110686384 A CN 202110686384A CN 113240477 A CN113240477 A CN 113240477A
Authority
CN
China
Prior art keywords
order
driver
information
receiving
probability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110686384.7A
Other languages
English (en)
Inventor
陈震
张�雄
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Pintu Beijing Information Technology Co ltd
Original Assignee
Pintu Beijing Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pintu Beijing Information Technology Co ltd filed Critical Pintu Beijing Information Technology Co ltd
Priority to CN202110686384.7A priority Critical patent/CN113240477A/zh
Publication of CN113240477A publication Critical patent/CN113240477A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0283—Price estimation or determination
    • G06Q30/0284—Time or distance, e.g. usage of parking meters or taximeters
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
    • G06Q10/06393—Score-carding, benchmarking or key performance indicator [KPI] analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q50/40—

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Traffic Control Systems (AREA)

Abstract

本发明提供了一种订单派发方法、订单派发装置和可读存储介质。订单派发方法包括：按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中预设规则为一个司机终端分配一个待处理订单，M和N均为大于或等于1的整数；确定每种分配方式下M个司机终端的总接单概率；将总接单概率最高的分配方式确定为目标分配方式，按照目标分配方式为M个司机终端分配N个待处理订单。本申请实施例通过能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。

Description

订单派发方法、订单派发装置和可读存储介质
技术领域
本发明涉及网约出租车技术领域，具体而言，涉及一种订单派发方法、订单派发装置和可读存储介质。
背景技术
在相关技术中，网约车服务中，出租车司机接单主要依靠网络平台派发。而网络平台对于订单的派发基于随机分配原则，导致分配给司机的订单可能与当前司机情况不符合，可能会导致司机“拒接”或乘客“撤单”，导致系统的派单效率低下，司机、乘客的体验都不好。
发明内容
本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。
为此，本发明的第一方面提出一种订单派发方法。
本发明的第二方面提出一种订单派发装置。
本发明的第三方面提出一种可读存储介质。
有鉴于此，本发明的第一方面提供了一种订单派发方法，包括：按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中预设规则为一个司机终端分配一个待处理订单，M和N均为大于或等于1的整数；确定每种分配方式下M个司机终端的总接单概率；将总接单概率最高的分配方式确定为目标分配方式，按照目标分配方式为M个司机终端分配N个待处理订单。
在该技术方案中，系统中存在有M个可接单的司机终端，和N个待处理订单，其中，一个可接单的司机终端则对应于一辆状态为“空车”的运载车辆，一个单处理订单则对应于一个从A点出发去到B点的用车请求。网约车系统按照预设规则，将当前的N个待处理订单分配给M个司机终端，其中，在保证为一个司机终端分配一个待处理订单的规则下，穷尽全部的排列组合可能，最终得到多个排列方式。
其中，每种排列方式下，司机终端与待处理订单的对应方式均不同。进一步地，分别计算在每种排列方式下，M个司机终端的总接单概率，也即一种分配方式下的总接单概率，并按照总接单概率的大小顺序，对多种分配方式进行排序。
再进一步地，选取全部分配方式中，总接单概率最高的一种排列方式，作为目标排列方式，因此目标排列方式也就是当前的M个“空车”和N个“打车乘客”之间的最优分配方案。
本申请实施例通过对当前能够接单的车辆和有用车需求的乘客进行排列，选出其中总接单概率最高的分配方式，来为当前可接单的车辆分配用车需求的订单，从而使得在分配订单式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
另外，本发明提供的上述技术方案中的订单派发方法还可以具有如下附加技术特征：
在上述技术方案中，确定每种分配方式下M个司机终端的总接单概率，包括：获取M个司机终端中，第一司机终端的历史接单信息和第一状态信息；获取为第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；根据历史接单信息、第一状态信息、历史下单信息和第二状态信息确定第一司机终端的当前接单概率；根据M个当前接单概率的总和确定总接单概率。
在该技术方案中，在计算总接单概率时，首先获取当前的M个司机终端中的第一司机终端的历史接单信息和第一状态信息，该历史接单信息可以描绘司机的历史运营情况，如评分、好评率、拒载率等。而第一状态信息则可以描绘该司机的当前状态，如位置、是否处于拥堵状态、车辆续航等。其中，能够理解的是，第一司机终端指的是M个司机终端中的任一个终端，而非特指M个司机终端中的“某个终端”。
进一步地，按照当前分配方法，确定在当前分配方法下分配给该第一司机终端的待处理订单，并进一步获取该待处理订单对应的乘客终端的历史下单信息和第二状态信息，其中，历史状态信息可以描绘乘客的历史用车情况，如评分、是否有“逃单”行为等，而第二状态则可以描绘乘客的当前状态，如上车地点、下车地点、是否途径拥堵路段等。
通过上述历史接单信息、第一状态信息、历史下单信息和第二状态信息，能够对司机画像和乘客画像进行描绘，从而根据平台预设的算法，和司机画像、乘客画像中各子项目的预设权重，能够准确地算出第一司机终端的当前接单概率。然后，将M个“第一司机终端”的接单概率进行加和，即可得到当前分配方式下的总接单概率。
进一步地，按照相同的方式，对每种分配方式下的总接单概率进行分别计算，并选出其中总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在上述任一技术方案中，历史接单信息包括：历史接单量和历史接单概率；第一状态信息包括：第一位置信息和对应的司机身份信息；历史下单信息包括：历史下单量和历史被接单概率；第二状态信息包括：第二位置信息和目的地信息。
在该技术方案中，司机终端的历史接单信息包括历史接单量和历史接单概率，其中，历史接单量越大，历史接单概率越大，则说明司机接单意愿越强。乘客终端的历史下单信息包括历史下单量和历史被接单概率，历史下单量越大，历史被接单概率越大，则说明该乘客经常使用网约车平台，是“常客”，司机对该乘客的订单的接受概率也越高。
进一步地，司机终端的第一状态信息包括第一位置信息和司机身份信息，其中，第一位置信息也就是当前车辆所处的地理位置，而司机身份信息则包含了司机服务质量评分、投诉量、好评量等。乘客终端的第二状态信息包括第二位置信息和目的地信息，第二位置信息也即当前乘客的叫车位置，也即上车位置，而目的地信息则是该叫车订单的“目的地”。
能够理解的是，车辆的第一位置与乘客的第二位置越接近，司机评价越好，目的地与上车位置之间的路途越平顺(如高速公路比例高、堵车路段比例低)，则对应的接单概率就越高，从而得到当前司机对当前乘客的“接单概率”，最终得到当前分配方式下的总接单概率。
通过选出总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单。
在上述任一技术方案中，在按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式之前，订单派发方法还包括：
接收N个乘客终端发送的下单请求，根据下单请求生成对应的N个待处理订单；获取司机终端的接单状态，根据接单状态确定处于可接单状态的M个司机终端。
在该技术方案中，网约车平台接收来自乘客终端发送的下单请求，其中，乘客终端可以是手机、平板电脑、个人计算机等设备，用户通过手机等电子设备，安装网约车平台的应用程序，并通过应用程序进行下单。在下单时，可以通过GPS(Global PositioningSystem，全球定位系统)获取用户的当前位置作为上车地点，并由用户手动输入目的地作为下车地点。网约车平台实时接收乘客终端的下单请求，并基于每一个下单请求，生成一个待处理订单，在有N个乘客终端发起下单请求的情况下，平台会生成N个待处理订单。
进一步地，平台获取司机终端的接单状态。具体地，可以通过出租车的计价器处于“扣表”状态还是“抬表”状态，判断司机终端是否处于可接单状态。能够理解的是，如果计价器处于扣表状态，则代表当前不可接单，而处于抬表状态，则说明当前处于可接单状态。通过筛选处于可接单状态的出租车量，能够避免向“载客中”的出租车进行派单的情况，从而有效提高派单效率。
在上述任一技术方案中，在按照目标分配方式为M个司机终端分配N个待处理订单之后，订单派发方法还包括：
开启计时；在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
在该技术方案中，在按照最优的目标分配方式进行派单之后，根据系统设定，可以给每个司机终端预设时长的接单空窗期，如果司机在接单空窗期内接单，则订单建立，此时将接单的司机终端和被接单的待处理订单分别从司机池和订单池中拿出。
如果在预设时长之内，有部分订单没有被司机终端接单，同时有部分司机终端没有进行接单，具体为剩下有X个可接单的出租车量和Y个待处理订单，则继续按照相同的方式，对这些订单和车辆进行排列组合，并分别计算每种分配方式下的总接单概率，从而继续按照总接单概率最高的分配方式，为X个司机终端重新分配Y个待处理订单，以保证每次派单的平台接单率最大化，实现全局层面的最优派单。
在上述任一技术方案中，预设时长的范围为：大于或等于1秒，且小于或等于5秒。
在该技术方案中，预设时长也即留给司机终端的接单时间。其中，对于司机终端可以根据是否空闲来自动接单的情况下，预设时长可以设置的较短，如设置为1秒。如果司机习惯于手动接单，则预设时长可以设置为较长，如设置为5秒。
优选地，预设时长可以设置为3秒。
在上述任一技术方案中，订单派发方法还包括：
接收第二司机终端的扣表信号；响应于扣表信号，开启计费，并接收第二司机终端的抬表信号；响应于抬表信号，停止计费，并生成对应的账单信息；将账单信息发送至第二司机终端和对应的乘客终端。
在该技术方案中，在司机接单后，可根据司机终端的扣表信号来实现自动计费。具体地，当乘客上车后，司机会将计价器扣表。在接收到扣表信号后，网约车系统和计价器同步计费。在到底目的地后，司机抬表，此时网约车系统停止积分，计价器也会输出计费账单。此时，网约车服务器将系统计费的账单信息，同步发送到司机持有的司机终端，和乘客持有的乘客终端，从而以平台监管的方式，进行统一计费。
乘客可以根据计价器计费和平台计费是否一致，来判断是否存在“跳表”行为，从而一方面对司机进行有效监管，保证乘客利益，另一方面如果出现乘客“逃单”等情况，能够站在平台的身份为司机提供计费证明，同时保证了司机的利益，能够有效减少计费纠纷，提高网约车计费效率。
本申请第二方面提供了一种订单派发装置，包括：
分配模块，用于按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中预设规则为一个司机终端分配一个待处理订单，M和N均为大于或等于1的整数；
确定模块，用于确定每种分配方式下M个司机终端的总接单概率；将总接单概率最高的分配方式确定为目标分配方式，按照目标分配方式为M个司机终端分配N个待处理订单。
在该技术方案中，系统中存在有M个可接单的司机终端，和N个待处理订单，其中，一个可接单的司机终端则对应于一辆状态为“空车”的运载车辆，一个单处理订单则对应于一个从A点出发去到B点的用车请求。网约车系统按照预设规则，将当前的N个待处理订单分配给M个司机终端，其中，在保证为一个司机终端分配一个待处理订单的规则下，穷尽全部的排列组合可能，最终得到多个排列方式。
其中，每种排列方式下，司机终端与待处理订单的对应方式均不同。进一步地，分别计算在每种排列方式下，M个司机终端的总接单概率，也即一种分配方式下的总接单概率，并按照总接单概率的大小顺序，对多种分配方式进行排序。
再进一步地，选取全部分配方式中，总接单概率最高的一种排列方式，作为目标排列方式，因此目标排列方式也就是当前的M个“空车”和N个“打车乘客”之间的最优分配方案。
本申请实施例通过对当前能够接单的车辆和有用车需求的乘客进行排列，选出其中总接单概率最高的分配方式，来为当前可接单的车辆分配用车需求的订单，从而使得在分配订单式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在上述技术方案中，确定模块还用于：
获取M个司机终端的第一司机终端的历史接单信息和第一状态信息；
获取为第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；
根据历史接单信息、第一状态信息、历史下单信息和第二状态信息确定第一司机终端的当前接单概率；
根据M个当前接单概率的总和确定总接单概率。
在该技术方案中，在计算总接单概率时，首先获取当前的M个司机终端中的第一司机终端的历史接单信息和第一状态信息，该历史接单信息可以描绘司机的历史运营情况，如评分、好评率、拒载率等。而第一状态信息则可以描绘该司机的当前状态，如位置、是否处于拥堵状态、车辆续航等。其中，能够理解的是，第一司机终端指的是M个司机终端中的任一个终端，而非特指M个司机终端中的“某个终端”。
进一步地，按照当前分配方法，确定在当前分配方法下分配给该第一司机终端的待处理订单，并进一步获取该待处理订单对应的乘客终端的历史下单信息和第二状态信息，其中，历史状态信息可以描绘乘客的历史用车情况，如评分、是否有“逃单”行为等，而第二状态则可以描绘乘客的当前状态，如上车地点、下车地点、是否途径拥堵路段等。
通过上述历史接单信息、第一状态信息、历史下单信息和第二状态信息，能够对司机画像和乘客画像进行描绘，从而根据平台预设的算法，和司机画像、乘客画像中各子项目的预设权重，能够准确地算出第一司机终端的当前接单概率。然后，将M个“第一司机终端”的接单概率进行加和，即可得到当前分配方式下的总接单概率。
进一步地，按照相同的方式，对每种分配方式下的总接单概率进行分别计算，并选出其中总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在上述任一技术方案中，历史接单信息包括：历史接单量和历史接单概率；第一状态信息包括：第一位置信息和对应的司机身份信息；历史下单信息包括：历史下单量和历史被接单概率；第二状态信息包括：第二位置信息和目的地信息。
在该技术方案中，司机终端的历史接单信息包括历史接单量和历史接单概率，其中，历史接单量越大，历史接单概率越大，则说明司机接单意愿越强。乘客终端的历史下单信息包括历史下单量和历史被接单概率，历史下单量越大，历史被接单概率越大，则说明该乘客经常使用网约车平台，是“常客”，司机对该乘客的订单的接受概率也越高。
进一步地，司机终端的第一状态信息包括第一位置信息和司机身份信息，其中，第一位置信息也就是当前车辆所处的地理位置，而司机身份信息则包含了司机服务质量评分、投诉量、好评量等。乘客终端的第二状态信息包括第二位置信息和目的地信息，第二位置信息也即当前乘客的叫车位置，也即上车位置，而目的地信息则是该叫车订单的“目的地”。
能够理解的是，车辆的第一位置与乘客的第二位置越接近，司机评价越好，目的地与上车位置之间的路途越平顺(如高速公路比例高、堵车路段比例低)，则对应的接单概率就越高，从而得到当前司机对当前乘客的“接单概率”，最终得到当前分配方式下的总接单概率。
通过选出总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单。
在上述任一技术方案中，订单派发装置还包括：
接收模块，用于接收N个乘客终端发送的下单请求，根据下单请求生成对应的N个待处理订单；获取司机终端的接单状态，根据接单状态确定处于可接单状态的M个司机终端。
在该技术方案中，网约车平台接收来自乘客终端发送的下单请求，其中，乘客终端可以是手机、平板电脑、个人计算机等设备，用户通过手机等电子设备，安装网约车平台的应用程序，并通过应用程序进行下单。在下单时，可以通过GPS(Global PositioningSystem，全球定位系统)获取用户的当前位置作为上车地点，并由用户手动输入目的地作为下车地点。网约车平台实时接收乘客终端的下单请求，并基于每一个下单请求，生成一个待处理订单，在有N个乘客终端发起下单请求的情况下，平台会生成N个待处理订单。
进一步地，平台获取司机终端的接单状态。具体地，可以通过出租车的计价器处于“扣表”状态还是“抬表”状态，判断司机终端是否处于可接单状态。能够理解的是，如果计价器处于扣表状态，则代表当前不可接单，而处于抬表状态，则说明当前处于可接单状态。通过筛选处于可接单状态的出租车量，能够避免向“载客中”的出租车进行派单的情况，从而有效提高派单效率。
在上述任一技术方案中，订单派发装置还包括：
计时模块，用于开启计时；分配模块还用于在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
在该技术方案中，在按照最优的目标分配方式进行派单之后，根据系统设定，可以给每个司机终端预设时长的接单空窗期，如果司机在接单空窗期内接单，则订单建立，此时将接单的司机终端和被接单的待处理订单分别从司机池和订单池中拿出。
如果在预设时长之内，有部分订单没有被司机终端接单，同时有部分司机终端没有进行接单，具体为剩下有X个可接单的出租车量和Y个待处理订单，则继续按照相同的方式，对这些订单和车辆进行排列组合，并分别计算每种分配方式下的总接单概率，从而继续按照总接单概率最高的分配方式，为X个司机终端重新分配Y个待处理订单，以保证每次派单的平台接单率最大化，实现全局层面的最优派单。
在上述任一技术方案中，预设时长的范围为：大于或等于1秒，且小于或等于5秒。
在该技术方案中，预设时长也即留给司机终端的接单时间。其中，对于司机终端可以根据是否空闲来自动接单的情况下，预设时长可以设置的较短，如设置为1秒。如果司机习惯于手动接单，则预设时长可以设置为较长，如设置为5秒。
优选地，预设时长可以设置为3秒。
在上述任一技术方案中，订单派发装置还包括：
计费模块，用于接收第二司机终端的扣表信号；响应于扣表信号，开启计费，并接收第二司机终端的抬表信号；响应于抬表信号，停止计费，并生成对应的账单信息；将账单信息发送至第二司机终端和对应的乘客终端。
在该技术方案中，在司机接单后，可根据司机终端的扣表信号来实现自动计费。具体地，当乘客上车后，司机会将计价器扣表。在接收到扣表信号后，网约车系统和计价器同步计费。在到底目的地后，司机抬表，此时网约车系统停止积分，计价器也会输出计费账单。此时，网约车服务器将系统计费的账单信息，同步发送到司机持有的司机终端，和乘客持有的乘客终端，从而以平台监管的方式，进行统一计费。
乘客可以根据计价器计费和平台计费是否一致，来判断是否存在“跳表”行为，从而一方面对司机进行有效监管，保证乘客利益，另一方面如果出现乘客“逃单”等情况，能够站在平台的身份为司机提供计费证明，同时保证了司机的利益，能够有效减少计费纠纷，提高网约车计费效率。
本申请第三方面提供了一种可读存储介质，包括存储器和处理器，存储器上存储有程序或指令，程序或指令被处理器执行时实现如上述任一技术方案中的订单派发方法的步骤，因此，该可读存储介质也包括如上述任一技术方案中的订单派发方法的全部有益效果，为避免重复，在此不再赘述。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
图1示出了根据本申请实施例的订单派发方法的流程图之一；
图2示出了根据本申请实施例的订单派发方法的流程图之二；
图3示出了根据本申请实施例的订单派发方法的流程图之三；
图4示出了根据本申请实施例的订单派发装置的框图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
下面参照图1至图4描述根据本发明一些实施例所述订单派发方法、订单派发装置和可读存储介质。
在本申请的一些实施例中，提供了一种订单派发方法，图1示出了根据本申请实施例的订单派发方法的流程图之一，如图1所示，包括：
步骤102，按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式；
在步骤102中，预设规则为一个司机终端分配一个待处理订单，M和N均为大于或等于1的整数；
步骤104，确定每种分配方式下M个司机终端的总接单概率；
步骤106，将总接单概率最高的分配方式确定为目标分配方式，按照目标分配方式为M个司机终端分配N个待处理订单。
在本申请实施例中，系统中存在有M个可接单的司机终端，和N个待处理订单，其中，一个可接单的司机终端则对应于一辆状态为“空车”的运载车辆，一个单处理订单则对应于一个从A点出发去到B点的用车请求。网约车系统按照预设规则，将当前的N个待处理订单分配给M个司机终端，其中，在保证为一个司机终端分配一个待处理订单的规则下，穷尽全部的排列组合可能，最终得到多个排列方式。
其中，每种排列方式下，司机终端与待处理订单的对应方式均不同。进一步地，分别计算在每种排列方式下，M个司机终端的总接单概率，也即一种分配方式下的总接单概率，并按照总接单概率的大小顺序，对多种分配方式进行排序。
再进一步地，选取全部分配方式中，总接单概率最高的一种排列方式，作为目标排列方式，因此目标排列方式也就是当前的M个“空车”和N个“打车乘客”之间的最优分配方案。
本申请实施例通过对当前能够接单的车辆和有用车需求的乘客进行排列，选出其中总接单概率最高的分配方式，来为当前可接单的车辆分配用车需求的订单，从而使得在分配订单式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在本申请的一些实施例中，确定每种分配方式下M个司机终端的总接单概率，包括：获取M个司机终端中，第一司机终端的历史接单信息和第一状态信息；获取为第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；根据历史接单信息、第一状态信息、历史下单信息和第二状态信息确定第一司机终端的当前接单概率；根据M个当前接单概率的总和确定总接单概率。
在本申请实施例中，在计算总接单概率时，首先获取当前的M个司机终端中的第一司机终端的历史接单信息和第一状态信息，该历史接单信息可以描绘司机的历史运营情况，如评分、好评率、拒载率等。而第一状态信息则可以描绘该司机的当前状态，如位置、是否处于拥堵状态、车辆续航等。其中，能够理解的是，第一司机终端指的是M个司机终端中的任一个终端，而非特指M个司机终端中的“某个终端”。
进一步地，按照当前分配方法，确定在当前分配方法下分配给该第一司机终端的待处理订单，并进一步获取该待处理订单对应的乘客终端的历史下单信息和第二状态信息，其中，历史状态信息可以描绘乘客的历史用车情况，如评分、是否有“逃单”行为等，而第二状态则可以描绘乘客的当前状态，如上车地点、下车地点、是否途径拥堵路段等。
通过上述历史接单信息、第一状态信息、历史下单信息和第二状态信息，能够对司机画像和乘客画像进行描绘，从而根据平台预设的算法，和司机画像、乘客画像中各子项目的预设权重，能够准确地算出第一司机终端的当前接单概率。然后，将M个“第一司机终端”的接单概率进行加和，即可得到当前分配方式下的总接单概率。
进一步地，按照相同的方式，对每种分配方式下的总接单概率进行分别计算，并选出其中总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在本申请的一些实施例中，历史接单信息包括：历史接单量和历史接单概率；第一状态信息包括：第一位置信息和对应的司机身份信息；历史下单信息包括：历史下单量和历史被接单概率；第二状态信息包括：第二位置信息和目的地信息。
在本申请实施例中，司机终端的历史接单信息包括历史接单量和历史接单概率，其中，历史接单量越大，历史接单概率越大，则说明司机接单意愿越强。乘客终端的历史下单信息包括历史下单量和历史被接单概率，历史下单量越大，历史被接单概率越大，则说明该乘客经常使用网约车平台，是“常客”，司机对该乘客的订单的接受概率也越高。
进一步地，司机终端的第一状态信息包括第一位置信息和司机身份信息，其中，第一位置信息也就是当前车辆所处的地理位置，而司机身份信息则包含了司机服务质量评分、投诉量、好评量等。乘客终端的第二状态信息包括第二位置信息和目的地信息，第二位置信息也即当前乘客的叫车位置，也即上车位置，而目的地信息则是该叫车订单的“目的地”。
能够理解的是，车辆的第一位置与乘客的第二位置越接近，司机评价越好，目的地与上车位置之间的路途越平顺(如高速公路比例高、堵车路段比例低)，则对应的接单概率就越高，从而得到当前司机对当前乘客的“接单概率”，最终得到当前分配方式下的总接单概率。
通过选出总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单。
在本申请的一些实施例中，图2示出了根据本申请实施例的订单派发方法的流程图之二，如图2所示，在按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式之前，订单派发方法还包括：
步骤202，接收N个乘客终端发送的下单请求，根据下单请求生成对应的N个待处理订单；
步骤204，获取司机终端的接单状态，根据接单状态确定处于可接单状态的M个司机终端。
在本申请实施例中，网约车平台接收来自乘客终端发送的下单请求，其中，乘客终端可以是手机、平板电脑、个人计算机等设备，用户通过手机等电子设备，安装网约车平台的应用程序，并通过应用程序进行下单。在下单时，可以通过GPS(Global PositioningSystem，全球定位系统)获取用户的当前位置作为上车地点，并由用户手动输入目的地作为下车地点。网约车平台实时接收乘客终端的下单请求，并基于每一个下单请求，生成一个待处理订单，在有N个乘客终端发起下单请求的情况下，平台会生成N个待处理订单。
进一步地，平台获取司机终端的接单状态。具体地，可以通过出租车的计价器处于“扣表”状态还是“抬表”状态，判断司机终端是否处于可接单状态。能够理解的是，如果计价器处于扣表状态，则代表当前不可接单，而处于抬表状态，则说明当前处于可接单状态。通过筛选处于可接单状态的出租车量，能够避免向“载客中”的出租车进行派单的情况，从而有效提高派单效率。
在本申请的一些实施例中，在按照目标分配方式为M个司机终端分配N个待处理订单之后，订单派发方法还包括：
开启计时；在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
在本申请实施例中，在按照最优的目标分配方式进行派单之后，根据系统设定，可以给每个司机终端预设时长的接单空窗期，如果司机在接单空窗期内接单，则订单建立，此时将接单的司机终端和被接单的待处理订单分别从司机池和订单池中拿出。
如果在预设时长之内，有部分订单没有被司机终端接单，同时有部分司机终端没有进行接单，具体为剩下有X个可接单的出租车量和Y个待处理订单，则继续按照相同的方式，对这些订单和车辆进行排列组合，并分别计算每种分配方式下的总接单概率，从而继续按照总接单概率最高的分配方式，为X个司机终端重新分配Y个待处理订单，以保证每次派单的平台接单率最大化，实现全局层面的最优派单。
在本申请的一些实施例中，预设时长的范围为：大于或等于1秒，且小于或等于5秒。
在本申请实施例中，预设时长也即留给司机终端的接单时间。其中，对于司机终端可以根据是否空闲来自动接单的情况下，预设时长可以设置的较短，如设置为1秒。如果司机习惯于手动接单，则预设时长可以设置为较长，如设置为5秒。
优选地，预设时长可以设置为3秒。
在本申请的一些实施例中，图3示出了根据本申请实施例的订单派发方法的流程图之三，如图3所示，订单派发方法还包括：
步骤302，接收第二司机终端的扣表信号；
步骤304，响应于扣表信号，开启计费，并接收第二司机终端的抬表信号；
步骤306，响应于抬表信号，停止计费，并生成对应的账单信息；
步骤308，将账单信息发送至第二司机终端和对应的乘客终端。
在本申请实施例中，在司机接单后，可根据司机终端的扣表信号来实现自动计费。具体地，当乘客上车后，司机会将计价器扣表。在接收到扣表信号后，网约车系统和计价器同步计费。在到底目的地后，司机抬表，此时网约车系统停止积分，计价器也会输出计费账单。此时，网约车服务器将系统计费的账单信息，同步发送到司机持有的司机终端，和乘客持有的乘客终端，从而以平台监管的方式，进行统一计费。
乘客可以根据计价器计费和平台计费是否一致，来判断是否存在“跳表”行为，从而一方面对司机进行有效监管，保证乘客利益，另一方面如果出现乘客“逃单”等情况，能够站在平台的身份为司机提供计费证明，同时保证了司机的利益，能够有效减少计费纠纷，提高网约车计费效率。
在本申请的一些实施例中，提供了一种订单派发装置，图4示出了根据本申请实施例的订单派发装置的框图，如图4所示，订单派发装置400包括：
分配模块402，用于按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中预设规则为一个司机终端分配一个待处理订单，M和N均为大于或等于1的整数；
确定模块404，用于确定每种分配方式下M个司机终端的总接单概率；将总接单概率最高的分配方式确定为目标分配方式，按照目标分配方式为M个司机终端分配N个待处理订单。
在本申请实施例中，系统中存在有M个可接单的司机终端，和N个待处理订单，其中，一个可接单的司机终端则对应于一辆状态为“空车”的运载车辆，一个单处理订单则对应于一个从A点出发去到B点的用车请求。网约车系统按照预设规则，将当前的N个待处理订单分配给M个司机终端，其中，在保证为一个司机终端分配一个待处理订单的规则下，穷尽全部的排列组合可能，最终得到多个排列方式。
其中，每种排列方式下，司机终端与待处理订单的对应方式均不同。进一步地，分别计算在每种排列方式下，M个司机终端的总接单概率，也即一种分配方式下的总接单概率，并按照总接单概率的大小顺序，对多种分配方式进行排序。
再进一步地，选取全部分配方式中，总接单概率最高的一种排列方式，作为目标排列方式，因此目标排列方式也就是当前的M个“空车”和N个“打车乘客”之间的最优分配方案。
本申请实施例通过对当前能够接单的车辆和有用车需求的乘客进行排列，选出其中总接单概率最高的分配方式，来为当前可接单的车辆分配用车需求的订单，从而使得在分配订单式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在本申请的一些实施例中，确定模块404还用于：
获取M个司机终端的第一司机终端的历史接单信息和第一状态信息；
获取为第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；
根据历史接单信息、第一状态信息、历史下单信息和第二状态信息确定第一司机终端的当前接单概率；
根据M个当前接单概率的总和确定总接单概率。
在本申请实施例中，在计算总接单概率时，首先获取当前的M个司机终端中的第一司机终端的历史接单信息和第一状态信息，该历史接单信息可以描绘司机的历史运营情况，如评分、好评率、拒载率等。而第一状态信息则可以描绘该司机的当前状态，如位置、是否处于拥堵状态、车辆续航等。其中，能够理解的是，第一司机终端指的是M个司机终端中的任一个终端，而非特指M个司机终端中的“某个终端”。
进一步地，按照当前分配方法，确定在当前分配方法下分配给该第一司机终端的待处理订单，并进一步获取该待处理订单对应的乘客终端的历史下单信息和第二状态信息，其中，历史状态信息可以描绘乘客的历史用车情况，如评分、是否有“逃单”行为等，而第二状态则可以描绘乘客的当前状态，如上车地点、下车地点、是否途径拥堵路段等。
通过上述历史接单信息、第一状态信息、历史下单信息和第二状态信息，能够对司机画像和乘客画像进行描绘，从而根据平台预设的算法，和司机画像、乘客画像中各子项目的预设权重，能够准确地算出第一司机终端的当前接单概率。然后，将M个“第一司机终端”的接单概率进行加和，即可得到当前分配方式下的总接单概率。
进一步地，按照相同的方式，对每种分配方式下的总接单概率进行分别计算，并选出其中总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单，因此能够极大的提高网约车系统的派单效率，使乘客和司机双方的使用体验均得到提升。
在本申请的一些实施例中，历史接单信息包括：历史接单量和历史接单概率；第一状态信息包括：第一位置信息和对应的司机身份信息；历史下单信息包括：历史下单量和历史被接单概率；第二状态信息包括：第二位置信息和目的地信息。
在本申请实施例中，司机终端的历史接单信息包括历史接单量和历史接单概率，其中，历史接单量越大，历史接单概率越大，则说明司机接单意愿越强。乘客终端的历史下单信息包括历史下单量和历史被接单概率，历史下单量越大，历史被接单概率越大，则说明该乘客经常使用网约车平台，是“常客”，司机对该乘客的订单的接受概率也越高。
进一步地，司机终端的第一状态信息包括第一位置信息和司机身份信息，其中，第一位置信息也就是当前车辆所处的地理位置，而司机身份信息则包含了司机服务质量评分、投诉量、好评量等。乘客终端的第二状态信息包括第二位置信息和目的地信息，第二位置信息也即当前乘客的叫车位置，也即上车位置，而目的地信息则是该叫车订单的“目的地”。
能够理解的是，车辆的第一位置与乘客的第二位置越接近，司机评价越好，目的地与上车位置之间的路途越平顺(如高速公路比例高、堵车路段比例低)，则对应的接单概率就越高，从而得到当前司机对当前乘客的“接单概率”，最终得到当前分配方式下的总接单概率。
通过选出总接单概率最高的分配方式作为目标分配方式，能够使得每次派单的平台接单率最大化，实现全局层面的最优派单。
在本申请的一些实施例中，订单派发装置还包括：
接收模块406，用于接收N个乘客终端发送的下单请求，根据下单请求生成对应的N个待处理订单；获取司机终端的接单状态，根据接单状态确定处于可接单状态的M个司机终端。
在本申请实施例中，网约车平台接收来自乘客终端发送的下单请求，其中，乘客终端可以是手机、平板电脑、个人计算机等设备，用户通过手机等电子设备，安装网约车平台的应用程序，并通过应用程序进行下单。在下单时，可以通过GPS(Global PositioningSystem，全球定位系统)获取用户的当前位置作为上车地点，并由用户手动输入目的地作为下车地点。网约车平台实时接收乘客终端的下单请求，并基于每一个下单请求，生成一个待处理订单，在有N个乘客终端发起下单请求的情况下，平台会生成N个待处理订单。
进一步地，平台获取司机终端的接单状态。具体地，可以通过出租车的计价器处于“扣表”状态还是“抬表”状态，判断司机终端是否处于可接单状态。能够理解的是，如果计价器处于扣表状态，则代表当前不可接单，而处于抬表状态，则说明当前处于可接单状态。通过筛选处于可接单状态的出租车量，能够避免向“载客中”的出租车进行派单的情况，从而有效提高派单效率。
在本申请的一些实施例中，订单派发装置还包括：
计时模块408，用于开启计时；分配模块402还用于在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
在本申请实施例中，在按照最优的目标分配方式进行派单之后，根据系统设定，可以给每个司机终端预设时长的接单空窗期，如果司机在接单空窗期内接单，则订单建立，此时将接单的司机终端和被接单的待处理订单分别从司机池和订单池中拿出。
如果在预设时长之内，有部分订单没有被司机终端接单，同时有部分司机终端没有进行接单，具体为剩下有X个可接单的出租车量和Y个待处理订单，则继续按照相同的方式，对这些订单和车辆进行排列组合，并分别计算每种分配方式下的总接单概率，从而继续按照总接单概率最高的分配方式，为X个司机终端重新分配Y个待处理订单，以保证每次派单的平台接单率最大化，实现全局层面的最优派单。
在本申请的一些实施例中，预设时长的范围为：大于或等于1秒，且小于或等于5秒。
在本申请实施例中，预设时长也即留给司机终端的接单时间。其中，对于司机终端可以根据是否空闲来自动接单的情况下，预设时长可以设置的较短，如设置为1秒。如果司机习惯于手动接单，则预设时长可以设置为较长，如设置为5秒。
优选地，预设时长可以设置为3秒。
在本申请的一些实施例中，订单派发装置还包括：
计费模块410，用于接收第二司机终端的扣表信号；响应于扣表信号，开启计费，并接收第二司机终端的抬表信号；响应于抬表信号，停止计费，并生成对应的账单信息；将账单信息发送至第二司机终端和对应的乘客终端。
在本申请实施例中，在司机接单后，可根据司机终端的扣表信号来实现自动计费。具体地，当乘客上车后，司机会将计价器扣表。在接收到扣表信号后，网约车系统和计价器同步计费。在到底目的地后，司机抬表，此时网约车系统停止积分，计价器也会输出计费账单。此时，网约车服务器将系统计费的账单信息，同步发送到司机持有的司机终端，和乘客持有的乘客终端，从而以平台监管的方式，进行统一计费。
乘客可以根据计价器计费和平台计费是否一致，来判断是否存在“跳表”行为，从而一方面对司机进行有效监管，保证乘客利益，另一方面如果出现乘客“逃单”等情况，能够站在平台的身份为司机提供计费证明，同时保证了司机的利益，能够有效减少计费纠纷，提高网约车计费效率。
在本申请的一些实施例中，提供了一种可读存储介质，包括存储器和处理器，存储器上存储有程序或指令，程序或指令被处理器执行时实现如上述任一实施例中的订单派发方法的步骤，因此，该可读存储介质也包括如上述任一实施例中的订单派发方法的全部有益效果，为避免重复，在此不再赘述。
本发明的描述中，术语“多个”则指两个或两个以上，除非另有明确的限定，术语“上”、“下”等指示的方位或位置关系为基于附图所述的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制；术语“连接”、“安装”、“固定”等均应做广义理解，例如，“连接”可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。
在本发明的描述中，术语“一个实施例”、“一些实施例”、“具体实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或特点包含于本发明的至少一个实施例或示例中。在本发明中，对上述术语的示意性表述不一定指的是相同的实施例或实例。而且，描述的具体特征、结构、材料或特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (15)

1.一种订单派发方法，其特征在于，包括：
按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中所述预设规则为一个所述司机终端分配一个所述待处理订单，M和N均为大于或等于1的整数；
确定每种所述分配方式下所述M个司机终端的总接单概率；
将所述总接单概率最高的所述分配方式确定为目标分配方式，按照所述目标分配方式为所述M个司机终端分配所述N个待处理订单。
2.根据权利要求1所述的订单派发方法，其特征在于，所述确定每种所述分配方式下所述M个司机终端的总接单概率，包括：
获取所述M个司机终端中，第一司机终端的历史接单信息和第一状态信息；
获取为所述第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；
根据所述历史接单信息、所述第一状态信息、所述历史下单信息和所述第二状态信息确定所述第一司机终端的当前接单概率；
根据M个所述当前接单概率的总和确定所述总接单概率。
3.根据权利要求2所述的订单派发方法，其特征在于，
所述历史接单信息包括：历史接单量和历史接单概率；
所述第一状态信息包括：第一位置信息和对应的司机身份信息；
所述历史下单信息包括：历史下单量和历史被接单概率；
所述第二状态信息包括：第二位置信息和目的地信息。
4.根据权利要求1所述的订单派发方法，其特征在于，在所述按照预设规则，为所述M个司机终端分配所述N个待处理订单，得到多种分配方式之前，所述订单派发方法还包括：
接收N个乘客终端发送的下单请求，根据所述下单请求生成对应的所述N个待处理订单；
获取司机终端的接单状态，根据所述接单状态确定处于可接单状态的M个司机终端。
5.根据权利要求1所述的订单派发方法，其特征在于，在所述按照所述目标分配方式为所述M个司机终端分配所述N个待处理订单之后，所述订单派发方法还包括：
开启计时；
在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
6.根据权利要求5所述的订单派发方法，其特征在于，所述预设时长的范围为：大于或等于1秒，且小于或等于5秒。
7.根据权利要求1至6中任一项所述的订单派发方法，其特征在于，还包括：
接收第二司机终端的扣表信号；
响应于所述扣表信号，开启计费，并接收所述第二司机终端的抬表信号；
响应于所述抬表信号，停止计费，并生成对应的账单信息；
将所述账单信息发送至所述第二司机终端和对应的乘客终端。
8.一种订单派发装置，其特征在于，包括：
分配模块，用于按照预设规则，为M个司机终端分配N个待处理订单，得到多种分配方式，其中所述预设规则为一个所述司机终端分配一个所述待处理订单，M和N均为大于或等于1的整数；
确定模块，用于确定每种所述分配方式下所述M个司机终端的总接单概率；将所述总接单概率最高的所述分配方式确定为目标分配方式，按照所述目标分配方式为所述M个司机终端分配所述N个待处理订单。
9.根据权利要求8所述的订单派发装置，其特征在于，所述确定模块还用于：
获取所述M个司机终端的第一司机终端的历史接单信息和第一状态信息；
获取为所述第一司机终端分配的待处理订单对应的乘客终端的历史下单信息和第二状态信息；
根据所述历史接单信息、所述第一状态信息、所述历史下单信息和所述第二状态信息确定所述第一司机终端的当前接单概率；
根据M个所述当前接单概率的总和确定所述总接单概率。
10.根据权利要求9所述的订单派发装置，其特征在于，
所述历史接单信息包括：历史接单量和历史接单概率；
所述第一状态信息包括：第一位置信息和对应的司机身份信息；
所述历史下单信息包括：历史下单量和历史被接单概率；
所述第二状态信息包括：第二位置信息和目的地信息。
11.根据权利要求8所述的订单派发装置，其特征在于，还包括：
接收模块，用于接收N个乘客终端发送的下单请求，根据所述下单请求生成对应的所述N个待处理订单；获取司机终端的接单状态，根据所述接单状态确定处于可接单状态的M个司机终端。
12.根据权利要求8所述的订单派发装置，其特征在于，还包括：
计时模块，用于开启计时；
所述分配模块还用于在计时时长达到预设时长后，重新为未接单的X个司机终端分配未被接单的Y个待处理订单，其中X小于或等于N，Y小于或等于M。
13.根据权利要求12所述的订单派发装置，其特征在于，所述预设时长的范围为：大于或等于1秒，且小于或等于5秒。
14.根据权利要求8至13中任一项所述的订单派发装置，其特征在于，还包括：
计费模块，用于接收第二司机终端的扣表信号；响应于所述扣表信号，开启计费，并接收所述第二司机终端的抬表信号；响应于所述抬表信号，停止计费，并生成对应的账单信息；将所述账单信息发送至所述第二司机终端和对应的乘客终端。
15.一种可读存储介质，其特征在于，包括存储器和处理器，所述存储器上存储有程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至7中任一项所述的订单派发方法的步骤。
CN202110686384.7A 2021-06-21 2021-06-21 订单派发方法、订单派发装置和可读存储介质 Pending CN113240477A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110686384.7A CN113240477A (zh) 2021-06-21 2021-06-21 订单派发方法、订单派发装置和可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110686384.7A CN113240477A (zh) 2021-06-21 2021-06-21 订单派发方法、订单派发装置和可读存储介质

Publications (1)

Publication Number Publication Date
CN113240477A true CN113240477A (zh) 2021-08-10

Family

ID=77140514

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110686384.7A Pending CN113240477A (zh) 2021-06-21 2021-06-21 订单派发方法、订单派发装置和可读存储介质

Country Status (1)

Country Link
CN (1) CN113240477A (zh)

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017088828A1 (en) * 2015-11-26 2017-06-01 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for allocating sharable orders
CN108182524A (zh) * 2017-12-26 2018-06-19 北京三快在线科技有限公司 一种订单分配方法及装置、电子设备
WO2018176939A1 (en) * 2017-03-27 2018-10-04 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for carpooling
US20180357893A1 (en) * 2017-06-07 2018-12-13 International Business Machines Corporation Uncertainty modeling in traffic demand prediction
CN109360278A (zh) * 2018-10-31 2019-02-19 石家庄铁道大学 出租车计价方法、系统及服务器
CN109829621A (zh) * 2018-12-28 2019-05-31 深圳市元征科技股份有限公司 一种网约车派单方法及装置
CN110110871A (zh) * 2018-02-01 2019-08-09 北京嘀嘀无限科技发展有限公司 一种订单分配的方法和系统
CN110570277A (zh) * 2019-08-29 2019-12-13 北京趣拿软件科技有限公司 订单的派发方法及装置
CN111080048A (zh) * 2018-10-22 2020-04-28 北京嘀嘀无限科技发展有限公司 预约打车订单的派单方法、装置、电子设备及储存介质
CN111353676A (zh) * 2018-12-24 2020-06-30 北京嘀嘀无限科技发展有限公司 订单分配方法、系统、计算机设备和计算机可读存储介质
CN111553645A (zh) * 2020-06-08 2020-08-18 北京顺达同行科技有限公司 订单分派方法、装置、计算机设备和存储介质
CN112396707A (zh) * 2020-11-02 2021-02-23 支付宝(杭州)信息技术有限公司 乘车费用计算方法及装置

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017088828A1 (en) * 2015-11-26 2017-06-01 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for allocating sharable orders
WO2018176939A1 (en) * 2017-03-27 2018-10-04 Beijing Didi Infinity Technology And Development Co., Ltd. Systems and methods for carpooling
US20180357893A1 (en) * 2017-06-07 2018-12-13 International Business Machines Corporation Uncertainty modeling in traffic demand prediction
CN108182524A (zh) * 2017-12-26 2018-06-19 北京三快在线科技有限公司 一种订单分配方法及装置、电子设备
CN110110871A (zh) * 2018-02-01 2019-08-09 北京嘀嘀无限科技发展有限公司 一种订单分配的方法和系统
CN111080048A (zh) * 2018-10-22 2020-04-28 北京嘀嘀无限科技发展有限公司 预约打车订单的派单方法、装置、电子设备及储存介质
CN109360278A (zh) * 2018-10-31 2019-02-19 石家庄铁道大学 出租车计价方法、系统及服务器
CN111353676A (zh) * 2018-12-24 2020-06-30 北京嘀嘀无限科技发展有限公司 订单分配方法、系统、计算机设备和计算机可读存储介质
CN109829621A (zh) * 2018-12-28 2019-05-31 深圳市元征科技股份有限公司 一种网约车派单方法及装置
CN110570277A (zh) * 2019-08-29 2019-12-13 北京趣拿软件科技有限公司 订单的派发方法及装置
CN111553645A (zh) * 2020-06-08 2020-08-18 北京顺达同行科技有限公司 订单分派方法、装置、计算机设备和存储介质
CN112396707A (zh) * 2020-11-02 2021-02-23 支付宝(杭州)信息技术有限公司 乘车费用计算方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
郑小红;龙军;蔡志平;: "关于网约车订单分配策略的综述", 计算机工程与科学, no. 07, pages 130 - 138 *

Similar Documents

Publication Publication Date Title
CN109716367B (zh) 用于预定运输服务的方法和系统
JP7432649B2 (ja) ライドシェアリング（相乗り）を管理するためのシステムと方法
US11062415B2 (en) Systems and methods for allocating networked vehicle resources in priority environments
CN110832512B (zh) 用于减少提供运输服务等待时间的系统和方法
CN110189006B (zh) 车辆的调度方法、装置、计算机设备及其存储介质
US11132626B2 (en) Systems and methods for vehicle resource management
US11392861B2 (en) Systems and methods for managing a vehicle sharing facility
US20140149153A1 (en) Method and system for dynamic parking allocation in urban settings
WO2016135648A1 (en) Systems and methods for managing a vehicle sharing facility
EP3262831B1 (en) Telephone call placement
CN110826957A (zh) 车辆卸货调度方法、装置、设备和存储介质
US11334959B2 (en) Method and system for managing allocation of transportation services
US20200210905A1 (en) Systems and Methods for Managing Networked Vehicle Resources
KR101654201B1 (ko) 임대요금의 분배 방법 및 시스템
CN109816128A (zh) 网约车订单的处理方法、装置、设备及可读存储介质
JP2003058984A (ja) タクシーの配車サービス方法及びそのシステム、並びに見積処理プログラムを記録した記録媒体
CN113240477A (zh) 订单派发方法、订单派发装置和可读存储介质
CN114493236A (zh) 服务车辆分派方法、装置、设备、介质及程序产品
CN113808381B (zh) 公共交通工具调度方法、服务器以及存储介质
SG191453A1 (en) System and method for flexible and efficient public transportation
CN112330956B (zh) 车辆自动调度的控制方法及装置
US20230196236A1 (en) City management support apparatus, city management support method, and non-transitory computer-readable storage medium
JP2023062410A (ja) 情報処理システム、情報処理方法、及び情報処理プログラム
CN116580550A (zh) 信息处理装置以及信息处理方法
TR2021010686A2 (tr) Elektri̇kli̇ araçlarin şarj i̇stasyonunda rezervasyon yapmasini sağlayan bi̇r si̇stem

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination