共计 4960 个字符，预计需要花费 13 分钟才能阅读完成。
桔妹导读： 所谓需要响应式公交，就是依据用户出行需要，提供非固定路线的、可能实时拼单的公交系统。目前滴滴动静公交可通过灵便调配运力、实时布局行驶路线，为用户提供经济、中转、有座、高效的响应式公交服务。
1. 产品背景介绍
传统公交系统以固定路线和时间表的模式给公众提供出行服务。近年来，随着信息技术的疾速倒退以及与各行业的深度交融，个性化服务逐步衰亡。在公共交通畛域，滴滴、Uber、Lyft 等科技出行公司通过使用新技术赋能传统出行行业，推出了更加便捷、优质的出行解决方案。
目前，全国每天约有 2.5 亿人次抉择公共出行。滴滴本着让出行更美妙的愿景，依附把握的高质量的交通大数据的劣势，一直考虑改良公共出行畛域的解决方案，踊跃配合交管部门等合作伙伴一起用技术力量改善城市交通，普惠公众出行。
在此背景下，滴滴需要响应式公交服务应运而生。其依据用户的个性化出行需要灵便调整运力，针对客流和虚构站点实时计算最优门路，疾速进行公交运力资源动静调配，实现全局效率最优。可无效补救传统公交在特定区域、特定时段内，运力和需要不匹配的问题，晋升公共交通运行效率，无效满足乘客出行的多元需要，无效晋升用户公共出行体验，减少公共交通可达性。目前该业务已在青岛、西安等多座城市落地，为用户提供经济、中转、有座、少步行的响应式公交服务。
在 ToG、ToB 的单干过程中，滴滴翻新公交团队次要致力于输入产品技术能力，赋能 B 端，孵化多场景下多样化的产品解决方案。公共出行的细分场景比拟多样化，有通勤、定点疏散、商务、游览、城际等类枢纽场景，有社区、产业园、大学城等类微循环场景，不同场景下可设计出不同的公交产品模式。同时须要一整套的经营体系来反对产品的运行，若各 B 端自研，老本高、周期长、危险大。和滴滴需要响应式公交技术平台产品对接，可大大降低合作方老本，减速产品落地。同时助力晋升公共出行信息化、网约化程度，让乘客便捷获取实时、精确的出行信息，让经营主体实时监控车辆经营状态、及时理解用户诉求。
2. 公交业务模型
咱们说出行问题，实质上是解决时空问题，公交出行同样如此。上面通过对业务模型的形象，拆解模型图层，如下图所示。第一层是动态区域站点层，站点能够规划设计大、中、虚构站点；第二层是线路层，刻画站点之间的通达门路；第三层是一体化服务层，通过各种模式来进行人车接送，调度等服务。不同出行场景下，时空散布存在差别，能够通过 3 层的不同模式来最优化公交服务。图中右上角区域，出行工夫、空间都很密集，这种场景下个别布局大中站点、固定路线、投入大车、固定排班的枢纽模式为主；图中左下角区域，出行工夫、空间都不密集，这种状况下布局虚构小站、投入小车、实时聚合、动静的微循环模式为主；工夫密集、空间不密集和空间密集、工夫不密集两种状况下，可联合枢纽和微循环组合模式去经营比拟高效。
3. 产品服务架构
为了落地实现产品价值，基于滴滴根底产研能力，滴滴实现了一整套动静公交产品服务。底层依靠弹性云平台、地图、算法、调度引擎等根底能力，构建了人、车、线动静智能匹配的服务。利用端包含乘客端，司机端，还有数据经营治理平台。
4. 产品界面
上面是动静公交产品成果截图。前 3 张是乘客端，用户抉择上下车站点，登程工夫等实时呼叫或者预约出行，期待零碎响应，响应之后，乘客能够看到车辆车牌号、车辆地位、预计到站工夫等信息疏导用户乘坐。后 1 张是司机端，司机接到调配的行程工作后，会依照程序接送乘客。
5. 多样化场景反对
公交出行的场景自身会比拟多样化，有通勤场景，有枢纽疏散场景，有商务，游览，城际，社区，产业园大学城等各种不同场景，不同场景下可能适宜设计不同的公交产品模式来服务。
下图是一个客运站枢纽疏散场景，开明分时段班次动静线路。青岛西站出站乘客呼叫预约，零碎依据不同上下车站点，动静聚合，布局动静路线，将乘客疏散到下边的大片区域。
下图是一个大学城区域，投入中小巴经营，固定站点，齐全不固定线路。片区內乘客可实时呼叫或者预约，零碎实时聚合匹配，实时生成动静路线，司机依照零碎派发工作，按程序接送乘客。
为了撑持实现多样化产品，咱们做了对业务模型的对立形象。对公交服务来说，外围模块设计包含站线模式、成行模式、调车模式、合乘模式、计价领取模式、勾销模式等。线站模式包含固定线路、不固定线路、局部束缚固定等模式；成行模式包含固定班次成行、拼够人数成行，票款达标等模式；调车模式包含固定排定打算、实时动静最优、轮循等模式；合乘模式包含排班乘坐、效率优先合乘、乘客体验平衡等模式；计价模式包含固定票价、阶梯票价、里程计价等模式；领取模式包含前领取、后领取、不领取等模式；勾销模式包含不可勾销，收费勾销，惩办勾销等。在这个业务模型中每种模式都模版化，经营方能够依据场景理论状况，自在灵便抉择组合，疾速发明落地经营新产品。
6. 线站模型升维
需要响应式公交汇合了网约车的便当和公交的优惠，是传统公交的一种翻新，其本质还是一种公共交通模式，强调布局性，须要有线站模型的规划设计。
为了表白多样化的产品经营状态，咱们升维了线站模型，从目前行业內以线为主，降级拓展为网状结构，配合站站通达性束缚图，关上线路的表白空间，能发明出更多可能的灵便线路状态。
公交的经营主体是各地的公交团体、客运公司、小范畴的园区、社区管委会等。不同的经营主体，依据本身的须要，经营特点以及当地交通规则以及理论状况，会设计差异化的线路束缚。
比拟典型的线路通达性设计束缚有:
- 局部或全副站点可能要求有绝对站序，不容许逆站序行驶，通常见于火车站到市区，机场到市区的这种集散地疏散场景。
- 要求设置一个或多个必经站，通常见于游览景区、车站、学校等。
- 容许零碎动静微调乘客下单的上车站点，以晋升车辆的经营效率，比方将乘客的上车站点批改到马路对面，通常见于园区，或者城区无方向的微循环场景，缩小车辆的调头。
- 非凡状况下，站点之间的门路轨迹要依照运力方理论线下教训布局的门路来设置，而不是依照导航服务的动静举荐线路来布局。
相似的场景还有很多。从性能上看，仿佛都是互不相干的定制化需要，然而从技术层面，咱们能够把这些需要都对立形象成一个非凡有向图的表白。如果须要站点绝对有序，咱们能够通过配置站点的连通性，来达到同样的成果。如果须要换站，咱们能够通过训练和开掘伎俩，来找出能够换站条件的站点，并通过引擎算法的撑持来实现最终的成果。
通过配置，开掘，训练等伎俩，结构出一个非凡有向图构造，并且使用到引擎内，最终转化成不同“定制化”需要，咱们称之为需要响应式公交的线网模型。
7. 区域和站线布局
因为是公交的属性，比拟强调区域，站线的布局。在布局方面，基于客流大数据，利用聚类等相干算法进行计算剖析，并且求解最优闭包区域，倡议站点设置，最优路径路线等。
8. 车辆排班和调度
不同的运营商，在不同场景下，经营形式是多种多样的。有在一个范畴内车辆不停巡游的场景，也有在多个场站之间定时排班的场景，还有在多个场站之间按需排班的场景。公交经营方通常会有一个线下调度员，专门负责车辆的调度工作，如何应用线上数据和技术手段，替换或者辅助车辆调度，并满足多种不同的场景需要，也是需要响应式公交面临的一个重要问题。
针对实际状况，咱们提炼出了动态和动静两种调度模式。
动态调度：依据分时段客流量以及方向散布，还有分时段路况等信息布局运力或者班次投入打算。并且利用智能算法，综合思考司机工作时长要求、疲劳驾驶、劳动周期、驾驶体现，以及车辆续驶里程、加油充电周期、全程用时等相干信息，智能计算举荐排班，而后人工疾速抉择和校对，高效产生最优排班打算。
动静调度：动静生成合乘路线之后，调度引擎会实时为其寻找最优的车辆进行匹配和分配任务。零碎会联合规定、车辆状态、车辆地位等一系列因素去评估和计算，如果通过计算断定路线工作能够被响应，就会对行程路线和车辆进行工作绑定，车辆接到工作按程序接送乘客。
上图是一个简略的示意图，途中，B1,B2 车辆曾经调配行程工作，正在执行既有行程，有 2 个未调配行程的车辆 B3 和 B4，实时在线期待派发工作，同时在该时刻咱们聚合造成了一个新的行程，后续呈现的订单能够持续在行程上聚合拼单，同时告知用户，行程曾经拼成，车辆信息稍后告知然而临时没有适合的车。咱们会依据运力规定，路况，预测发单状况去实时更新最合适的车辆，最终指定车辆 B4 去执行该未调配车辆的行程。
9. 系统核心架构
需要响应式公交次要由乘客端、司机端、治理后盾和引擎几个局部组成。整个零碎从用户呼单为终点开始运转，订单通过剖析解决后放入订单池，订单池以某个特定的频率向引擎发动拼单申请，引擎剖析申请，适配适合的算法，给订单撮合最优的车辆，并给车辆布局出接送人的程序，而后将后果返回给后盾零碎进行缓存。司机端和乘客端接管后盾的信息进行展现并对信息进行迭代更新，这样，就形成了一个残缺的零碎闭环。
整个零碎的架构简图如下：
10. 拼单和布局引擎
动静公交拼单和布局引擎次要是解决多车、多单在工夫和空间上的匹配问题，在满足各种先决条件下，尽可能多的拼成订单，同时确保司乘体验。公交车辆车型多样，有几座的，也有几十座以上的，相比网约车，动静公交在每个车辆怎么调配多个订单、多个订单如何组合不同路线两个维度上多了延长，而这种维度上的减少带来的是组合上指数级的增长。
假如某个场景下有 M 辆车、N 个订单同时拼单，可能的组合计划（车单无序组合）会有
种；另，某个计划上有 K 辆车拼成，某辆车上有 Q 个订单，则该计划下的解会有
种组合；则，实践上，M 车 N 单可能的组合计划数级别为：
如此规模的 VRP 问题，暴力检索是不可设想的。小规模区域下，能够通过传统运筹学领域的算法准确求解；当针对区域规模较大时，准确求解是不切实际的，须要寻找正当的智能算法，既要思考搜寻性能，也要正当躲避陷入部分最优。为了更好的应答这种 NP- 难问题，寻找更好的次优解是咱们解决问题的要害。
动静公交 VRP 问题，有它独特的限度要求（车载量限度、用户工夫窗限度、站点程序限度等等），这种状况下一个正当的初始解很重要，可能较大水平上缩减搜寻规模，这里咱们能够联合拼单逻辑，启发式生成初始解；搜寻过程中引入禁忌表防止反复操作；采纳变畛域搜寻防止陷入部分最优等等，在集中性和疏散性之间达到较好的均衡。另外，指标函数决定了搜寻的方向，如何设计正当的指标函数，如何均衡拼单率和体验之间的关系，始终是咱们摸索的方向。目前咱们也在布局通过机器学习智能举荐正当站点、疏导车辆正当散布等供需主动均衡计划。同时咱们也在利用已有的历史订单数据和用户行为数据通过深度学习的办法踊跃搭建咱们的仿真零碎，为针对不同经营区域独立建模搭建根底。
11. 开放平台
出于赋能公交行业的目标，除反对滴滴主 app 呼单外，咱们还提供一个开放平台单干模式，依附开放平台客户能够更加自主化的实现本身需要。
公交是一个多方单干的业务，技术平台以开放平台的模式来构建。应用凋谢 api 的形式，反对了多种形式的单干可能，经营方能够间接在滴滴 app 上经营产品，也能够通过咱们提供的凋谢 api 和 sdk 接入到自有零碎和 app 产品经营。
目前咱们的产品和零碎还有很多不欠缺的中央，也面对着很多的技术难点，欢送大家对咱们提出您贵重的意见，帮忙咱们更好的成长，谢谢。
梦在远方，路在脚下，咱们致力于为您提供最佳公共出行解决方案！
本文作者
2016 年退出滴滴，翻新公交负责人，次要负责动静公交整体业务架构设计。
2018 年退出滴滴，次要负责翻新公交乘客端后端、开放平台和仿真平台等工作。
2016 年退出滴滴，次要负责动静公交的司机端后端和布局引擎等工作。
2019 年退出滴滴，次要负责动静公交布局引擎和可视化平台等工作。
团队招聘
滴滴地图与公交事业部翻新公交团队，依靠滴滴地图导航技术和根底数据能力，应用机器学习和智能优化办法等技术，致力于为用户提供灵便、高效的公共出行解决方案。
团队长期招聘研发工程师，包含前端、后端、引擎策略等方向，欢送有趣味的小伙伴退出，可投递简历至 diditech@didiglobal.com，邮件请邮件主题请命名为「姓名 - 应聘部门 - 应聘方向」。
延长浏览
内容编辑 | Charlotte
分割咱们 | DiDiTech@didiglobal.com
滴滴技术 出品
