浅谈滴滴需求响应式公交背后的技术

时间 2020-09-30

原文原文链接

桔妹导读：所谓需求响应式公交，就是根据用户出行需求，提供非固定路线的、可以实时拼单的公交系统。目前滴滴动态公交可经过灵活调配运力、实时规划行驶路线，为用户提供经济、直达、有座、高效的响应式公交服务。前端

1. 产品背景介绍

传统公交系统以固定路线和时间表的形式给公众提供出行服务。近年来，随着信息技术的快速发展以及与各行业的深度融合，个性化服务逐渐兴起。在公共交通领域，滴滴、Uber、Lyft等科技出行公司经过运用新技术赋能传统出行行业，推出了更加便捷、优质的出行解决方案。算法

目前，全国天天约有2.5亿人次选择公共出行。滴滴本着让出行更美好的愿景，依靠掌握的高质量的交通大数据的优点，不断思索改进公共出行领域的解决方案，积极配合交管部门等合做伙伴一块儿用技术力量改善城市交通，普惠大众出行。后端

在此背景下，滴滴需求响应式公交服务应运而生。其根据用户的个性化出行需求灵活调整运力，针对客流和虚拟站点实时计算最优路径，快速进行公交运力资源动态调配，实现全局效率最优。可有效弥补传统公交在特定区域、特定时段内，运力和需求不匹配的问题，提高公共交通运行效率，有效知足乘客出行的多元需求，有效提高用户公共出行体验，增长公共交通可达性。目前该业务已在青岛、西安等多座城市落地，为用户提供经济、直达、有座、少步行的响应式公交服务。api

在ToG、ToB的合做过程当中，滴滴创新公交团队主要致力于输出产品技术能力，赋能B端，孵化多场景下多样化的产品解决方案。公共出行的细分场景比较多样化，有通勤、定点疏散、商务、旅游、城际等类枢纽场景，有社区、产业园、大学城等类微循环场景，不一样场景下可设计出不一样的公交产品模式。同时须要一整套的运营体系来支持产品的运转，若各B端自研，成本高、周期长、风险大。和滴滴需求响应式公交技术平台产品对接，可大大下降合做方成本，加速产品落地。同时助力提高公共出行信息化、网约化水平，让乘客便捷获取实时、准确的出行信息，让运营主体实时监控车辆运营状态、及时了解用户诉求。缓存

2. 公交业务模型

咱们说出行问题，本质上是解决时空问题，公交出行一样如此。下面经过对业务模型的抽象，拆解模型图层，以下图所示。第一层是静态区域站点层，站点能够规划设计大、中、虚拟站点；第二层是线路层，刻画站点之间的通达路径；第三层是一体化服务层，经过各类模式来进行人车接送，调度等服务。不一样出行场景下，时空分布存在差别，能够经过3层的不一样模式来最优化公交服务。图中右上角区域，出行时间、空间都很密集，这种场景下通常规划大中站点、固定路线、投入大车、固定排班的枢纽模式为主；图中左下角区域，出行时间、空间都不密集，这种状况下规划虚拟小站、投入小车、实时聚合、动态的微循环模式为主；时间密集、空间不密集和空间密集、时间不密集两种状况下，可结合枢纽和微循环组合模式去运营比较高效。
闭包

3. 产品服务架构

为了落地实现产品价值，基于滴滴基础产研能力，滴滴实现了一整套动态公交产品服务。底层依托弹性云平台、地图、算法、调度引擎等基础能力，构建了人、车、线动态智能匹配的服务。应用端包括乘客端，司机端，还有数据运营管理平台。
架构

4. 产品界面

下面是动态公交产品效果截图。前3张是乘客端，用户选择上下车站点，出发时间等实时呼叫或者预定出行，等待系统响应，响应以后，乘客能够看到车辆车牌号、车辆位置、预计到站时间等信息引导用户乘坐。后1张是司机端，司机接到分配的行程任务后，会按照顺序接送乘客。app

5. 多样化场景支持

公交出行的场景自己会比较多样化，有通勤场景，有枢纽疏散场景，有商务，旅游，城际，社区，产业园大学城等各类不一样场景，不一样场景下可能适合设计不一样的公交产品模式来服务。机器学习

下图是一个客运站枢纽疏散场景，开通分时段班次动态线路。青岛西站出站乘客呼叫预定，系统根据不一样上下车站点，动态聚合，规划动态路线，将乘客疏散到下边的大片区域。函数

下图是一个大学城区域，投入中小巴运营，固定站点，彻底不固定线路。片区內乘客可实时呼叫或者预定，系统实时聚合匹配，实时生成动态路线，司机按照系统派发任务，按顺序接送乘客。

为了支撑实现多样化产品，咱们作了对业务模型的统一抽象。对公交服务来讲，核心模块设计包括站线模式、成行模式、调车模式、合乘模式、计价支付模式、取消模式等。线站模式包括固定线路、不固定线路、部分约束固定等模式；成行模式包括固定班次成行、拼够人数成行，票款达标等模式；调车模式包括固定排定计划、实时动态最优、轮循等模式；合乘模式包括排班乘坐、效率优先合乘、乘客体验均衡等模式；计价模式包括固定票价、阶梯票价、里程计价等模式；支付模式包括前支付、后支付、不支付等模式；取消模式包括不可取消，免费取消，惩罚取消等。在这个业务模型中每种模式都模版化，运营方能够根据场景实际状况，自由灵活选择组合，快速创造落地运营新产品。

6. 线站模型升维

需求响应式公交集合了网约车的便利和公交的优惠，是传统公交的一种创新，其本质仍是一种公共交通形式，强调规划性，须要有线站模型的规划设计。

为了表达多样化的产品运营形态，咱们升维了线站模型，从目前行业內以线为主，升级拓展为网状结构，配合站站通达性约束图，打开线路的表达空间，能创造出更多可能的灵活线路形态。

公交的运营主体是各地的公交集团、客运公司、小范围的园区、社区管委会等。不一样的运营主体，根据自身的须要，运营特色以及当地交通规则以及实际状况，会设计差别化的线路约束。

比较典型的线路通达性设计约束有:

部分或所有站点可能要求有相对站序，不容许逆站序行驶，一般见于火车站到市区，机场到市区的这种集散地疏散场景。
要求设置一个或多个必经站，一般见于旅游景区、车站、学校等。
容许系统动态微调乘客下单的上车站点，以提高车辆的运营效率，好比将乘客的上车站点修改到马路对面，一般见于园区，或者城区无方向的微循环场景，减小车辆的调头。
特殊状况下，站点之间的路径轨迹要按照运力方实际线下经验规划的路径来设置，而不是按照导航服务的动态推荐线路来规划。

相似的场景还有不少。从功能上看，彷佛都是互不相关的定制化需求，可是从技术层面，咱们能够把这些需求都统一抽象成一个特殊有向图的表达。若是须要站点相对有序，咱们能够经过配置站点的连通性，来达到一样的效果。若是须要换站，咱们能够经过训练和挖掘手段，来找出能够换站条件的站点，并经过引擎算法的支撑来实现最终的效果。

经过配置，挖掘，训练等手段，构造出一个特殊有向图结构，而且运用到引擎内，最终转化成不一样“定制化”需求，咱们称之为需求响应式公交的线网模型。

7. 区域和站线规划

因为是公交的属性，比较强调区域，站线的规划。在规划方面，基于客流大数据，应用聚类等相关算法进行计算分析，而且求解最优闭包区域，建议站点设置，最优途径路线等。

8. 车辆排班和调度

不一样的运营商，在不一样场景下，运营方式是多种多样的。有在一个范围内车辆不停巡游的场景，也有在多个场站之间定时排班的场景，还有在多个场站之间按需排班的场景。公交运营方一般会有一个线下调度员，专门负责车辆的调度工做，如何使用线上数据和技术手段，替换或者辅助车辆调度，并知足多种不一样的场景需求，也是需求响应式公交面临的一个重要问题。

针对实际状况，咱们提炼出了静态和动态两种调度模式。

静态调度：根据分时段客流量以及方向分布，还有分时段路况等信息规划运力或者班次投入计划。而且利用智能算法，综合考虑司机工做时长要求、疲劳驾驶、休息周期、驾驶表现，以及车辆续驶里程、加油充电周期、全程用时等相关信息，智能计算推荐排班，而后人工快速选择和校订，高效产生最优排班计划。

动态调度：动态生成合乘路线以后，调度引擎会实时为其寻找最优的车辆进行匹配和分配任务。系统会结合规则、车辆状态、车辆位置等一系列因素去评估和计算，若是经过计算断定路线任务能够被响应，就会对行程路线和车辆进行任务绑定，车辆接到任务按顺序接送乘客。

上图是一个简单的示意图，途中，B1,B2车辆已经分配行程任务，正在执行既有行程，有2个未分配行程的车辆B3和B4，实时在线等待派发任务，同时在该时刻咱们聚合造成了一个新的行程，后续出现的订单能够继续在行程上聚合拼单，同时告知用户，行程已经拼成，车辆信息稍后告知可是暂时没有合适的车。咱们会根据运力规则，路况，预测发单状况去实时更新最合适的车辆，最终指定车辆B4去执行该未分配车辆的行程。

9. 系统核心架构

需求响应式公交主要由乘客端、司机端、管理后台和引擎几个部分组成。整个系统从用户呼单为起点开始运转，订单通过分析处理后放入订单池，订单池以某个特定的频率向引擎发起拼单请求，引擎分析请求，适配合适的算法，给订单撮合最优的车辆，并给车辆规划出接送人的顺序，而后将结果返回给后台系统进行缓存。司机端和乘客端接收后台的信息进行展现并对信息进行迭代更新，这样，就构成了一个完整的系统闭环。

整个系统的架构简图以下：

10. 拼单和规划引擎

动态公交拼单和规划引擎主要是解决多车、多单在时间和空间上的匹配问题，在知足各类先决条件下，尽量多的拼成订单，同时确保司乘体验。公交车辆车型多样，有几座的，也有几十座以上的，相比网约车，动态公交在每一个车辆怎么分配多个订单、多个订单如何组合不一样路线两个维度上多了延伸，而这种维度上的增长带来的是组合上指数级的增加。

假设某个场景下有M辆车、N个订单同时拼单，可能的组合方案（车单无序组合）会有

种；另，某个方案上有K辆车拼成，某辆车上有Q个订单，则该方案下的解会有

种组合；则，理论上，M车N单可能的组合方案数级别为：

如此规模的VRP问题，暴力检索是不可想象的。小规模区域下，能够经过传统运筹学范畴的算法精确求解；当针对区域规模较大时，精确求解是不切实际的，须要寻找合理的智能算法，既要考虑搜索性能，也要合理规避陷入局部最优。为了更好的应对这种NP-难问题，寻找更好的次优解是咱们解决问题的关键。

动态公交VRP问题，有它独特的限制要求（车载量限制、用户时间窗限制、站点顺序限制等等），这种状况下一个合理的初始解很重要，可以较大程度上缩减搜索规模，这里咱们能够结合拼单逻辑，启发式生成初始解；搜索过程当中引入禁忌表避免重复操做；采用变领域搜索避免陷入局部最优等等，在集中性和疏散性之间达到较好的平衡。另外，目标函数决定了搜索的方向，如何设计合理的目标函数，如何平衡拼单率和体验之间的关系，一直是咱们探索的方向。目前咱们也在布局经过机器学习智能推荐合理站点、引导车辆合理分布等供需自动平衡方案。同时咱们也在利用已有的历史订单数据和用户行为数据经过深度学习的方法积极搭建咱们的仿真系统，为针对不一样运营区域独立建模搭建基础。