桔妹導讀:所謂需求響應式公交,就是根據用戶出行需求,提供非固定路線的、可以實時拼單的公交系統。目前滴滴動態公交可經過靈活調配運力、實時規劃行駛路線,爲用戶提供經濟、直達、有座、高效的響應式公交服務。前端
傳統公交系統以固定路線和時間表的形式給公衆提供出行服務。近年來,隨着信息技術的快速發展以及與各行業的深度融合,個性化服務逐漸興起。在公共交通領域,滴滴、Uber、Lyft等科技出行公司經過運用新技術賦能傳統出行行業,推出了更加便捷、優質的出行解決方案。算法
目前,全國天天約有2.5億人次選擇公共出行。滴滴本着讓出行更美好的願景,依靠掌握的高質量的交通大數據的優點,不斷思索改進公共出行領域的解決方案,積極配合交管部門等合做夥伴一塊兒用技術力量改善城市交通,普惠大衆出行。後端
在此背景下,滴滴需求響應式公交服務應運而生。其根據用戶的個性化出行需求靈活調整運力,針對客流和虛擬站點實時計算最優路徑,快速進行公交運力資源動態調配,實現全局效率最優。可有效彌補傳統公交在特定區域、特定時段內,運力和需求不匹配的問題,提高公共交通運行效率,有效知足乘客出行的多元需求,有效提高用戶公共出行體驗,增長公共交通可達性。目前該業務已在青島、西安等多座城市落地,爲用戶提供經濟、直達、有座、少步行的響應式公交服務。api
在ToG、ToB的合做過程當中,滴滴創新公交團隊主要致力於輸出產品技術能力,賦能B端,孵化多場景下多樣化的產品解決方案。公共出行的細分場景比較多樣化,有通勤、定點疏散、商務、旅遊、城際等類樞紐場景,有社區、產業園、大學城等類微循環場景,不一樣場景下可設計出不一樣的公交產品模式。同時須要一整套的運營體系來支持產品的運轉,若各B端自研,成本高、週期長、風險大。和滴滴需求響應式公交技術平臺產品對接,可大大下降合做方成本,加速產品落地。同時助力提高公共出行信息化、網約化水平,讓乘客便捷獲取實時、準確的出行信息,讓運營主體實時監控車輛運營狀態、及時瞭解用戶訴求。緩存
咱們說出行問題,本質上是解決時空問題,公交出行一樣如此。下面經過對業務模型的抽象,拆解模型圖層,以下圖所示。第一層是靜態區域站點層,站點能夠規劃設計大、中、虛擬站點;第二層是線路層,刻畫站點之間的通達路徑;第三層是一體化服務層,經過各類模式來進行人車接送,調度等服務。不一樣出行場景下,時空分佈存在差別,能夠經過3層的不一樣模式來最優化公交服務。圖中右上角區域,出行時間、空間都很密集,這種場景下通常規劃大中站點、固定路線、投入大車、固定排班的樞紐模式爲主;圖中左下角區域,出行時間、空間都不密集,這種狀況下規劃虛擬小站、投入小車、實時聚合、動態的微循環模式爲主;時間密集、空間不密集和空間密集、時間不密集兩種狀況下,可結合樞紐和微循環組合模式去運營比較高效。
閉包
爲了落地實現產品價值,基於滴滴基礎產研能力,滴滴實現了一整套動態公交產品服務。底層依託彈性雲平臺、地圖、算法、調度引擎等基礎能力,構建了人、車、線動態智能匹配的服務。應用端包括乘客端,司機端,還有數據運營管理平臺。
架構
下面是動態公交產品效果截圖。前3張是乘客端,用戶選擇上下車站點,出發時間等實時呼叫或者預定出行,等待系統響應,響應以後,乘客能夠看到車輛車牌號、車輛位置、預計到站時間等信息引導用戶乘坐。後1張是司機端,司機接到分配的行程任務後,會按照順序接送乘客。app
公交出行的場景自己會比較多樣化,有通勤場景,有樞紐疏散場景,有商務,旅遊,城際,社區,產業園大學城等各類不一樣場景,不一樣場景下可能適合設計不一樣的公交產品模式來服務。機器學習
下圖是一個客運站樞紐疏散場景,開通分時段班次動態線路。青島西站出站乘客呼叫預定,系統根據不一樣上下車站點,動態聚合,規劃動態路線,將乘客疏散到下邊的大片區域。函數
下圖是一個大學城區域,投入中小巴運營,固定站點,徹底不固定線路。片區內乘客可實時呼叫或者預定,系統實時聚合匹配,實時生成動態路線,司機按照系統派發任務,按順序接送乘客。
爲了支撐實現多樣化產品,咱們作了對業務模型的統一抽象。對公交服務來講,核心模塊設計包括站線模式、成行模式、調車模式、合乘模式、計價支付模式、取消模式等。線站模式包括固定線路、不固定線路、部分約束固定等模式;成行模式包括固定班次成行、拼夠人數成行,票款達標等模式;調車模式包括固定排定計劃、實時動態最優、輪循等模式;合乘模式包括排班乘坐、效率優先合乘、乘客體驗均衡等模式;計價模式包括固定票價、階梯票價、里程計價等模式;支付模式包括前支付、後支付、不支付等模式;取消模式包括不可取消,免費取消,懲罰取消等。在這個業務模型中每種模式都模版化,運營方能夠根據場景實際狀況,自由靈活選擇組合,快速創造落地運營新產品。
需求響應式公交集合了網約車的便利和公交的優惠,是傳統公交的一種創新,其本質仍是一種公共交通形式,強調規劃性,須要有線站模型的規劃設計。
爲了表達多樣化的產品運營形態,咱們升維了線站模型,從目前行業內以線爲主,升級拓展爲網狀結構,配合站站通達性約束圖,打開線路的表達空間,能創造出更多可能的靈活線路形態。
公交的運營主體是各地的公交集團、客運公司、小範圍的園區、社區管委會等。不一樣的運營主體,根據自身的須要,運營特色以及當地交通規則以及實際狀況,會設計差別化的線路約束。
比較典型的線路通達性設計約束有:
相似的場景還有不少。從功能上看,彷佛都是互不相關的定製化需求,可是從技術層面,咱們能夠把這些需求都統一抽象成一個特殊有向圖的表達。若是須要站點相對有序,咱們能夠經過配置站點的連通性,來達到一樣的效果。若是須要換站,咱們能夠經過訓練和挖掘手段,來找出能夠換站條件的站點,並經過引擎算法的支撐來實現最終的效果。
經過配置,挖掘,訓練等手段,構造出一個特殊有向圖結構,而且運用到引擎內,最終轉化成不一樣「定製化」需求,咱們稱之爲需求響應式公交的線網模型。
因爲是公交的屬性,比較強調區域,站線的規劃。在規劃方面,基於客流大數據,應用聚類等相關算法進行計算分析,而且求解最優閉包區域,建議站點設置,最優途徑路線等。
不一樣的運營商,在不一樣場景下,運營方式是多種多樣的。有在一個範圍內車輛不停巡遊的場景,也有在多個場站之間定時排班的場景,還有在多個場站之間按需排班的場景。公交運營方一般會有一個線下調度員,專門負責車輛的調度工做,如何使用線上數據和技術手段,替換或者輔助車輛調度,並知足多種不一樣的場景需求,也是需求響應式公交面臨的一個重要問題。
針對實際狀況,咱們提煉出了靜態和動態兩種調度模式。
靜態調度:根據分時段客流量以及方向分佈,還有分時段路況等信息規劃運力或者班次投入計劃。而且利用智能算法,綜合考慮司機工做時長要求、疲勞駕駛、休息週期、駕駛表現,以及車輛續駛里程、加油充電週期、全程用時等相關信息,智能計算推薦排班,而後人工快速選擇和校訂,高效產生最優排班計劃。
動態調度:動態生成合乘路線以後,調度引擎會實時爲其尋找最優的車輛進行匹配和分配任務。系統會結合規則、車輛狀態、車輛位置等一系列因素去評估和計算,若是經過計算斷定路線任務能夠被響應,就會對行程路線和車輛進行任務綁定,車輛接到任務按順序接送乘客。
上圖是一個簡單的示意圖,途中,B1,B2車輛已經分配行程任務,正在執行既有行程,有2個未分配行程的車輛B3和B4,實時在線等待派發任務,同時在該時刻咱們聚合造成了一個新的行程,後續出現的訂單能夠繼續在行程上聚合拼單,同時告知用戶,行程已經拼成,車輛信息稍後告知可是暫時沒有合適的車。咱們會根據運力規則,路況,預測發單狀況去實時更新最合適的車輛,最終指定車輛B4去執行該未分配車輛的行程。
需求響應式公交主要由乘客端、司機端、管理後臺和引擎幾個部分組成。整個系統從用戶呼單爲起點開始運轉,訂單通過分析處理後放入訂單池,訂單池以某個特定的頻率向引擎發起拼單請求,引擎分析請求,適配合適的算法,給訂單撮合最優的車輛,並給車輛規劃出接送人的順序,而後將結果返回給後臺系統進行緩存。司機端和乘客端接收後臺的信息進行展現並對信息進行迭代更新,這樣,就構成了一個完整的系統閉環。
整個系統的架構簡圖以下:
動態公交拼單和規劃引擎主要是解決多車、多單在時間和空間上的匹配問題,在知足各類先決條件下,儘量多的拼成訂單,同時確保司乘體驗。公交車輛車型多樣,有幾座的,也有幾十座以上的,相比網約車,動態公交在每一個車輛怎麼分配多個訂單、多個訂單如何組合不一樣路線兩個維度上多了延伸,而這種維度上的增長帶來的是組合上指數級的增加。
假設某個場景下有M輛車、N個訂單同時拼單,可能的組合方案(車單無序組合)會有
種;另,某個方案上有K輛車拼成,某輛車上有Q個訂單,則該方案下的解會有
種組合;則,理論上,M車N單可能的組合方案數級別爲:
如此規模的VRP問題,暴力檢索是不可想象的。小規模區域下,能夠經過傳統運籌學範疇的算法精確求解;當針對區域規模較大時,精確求解是不切實際的,須要尋找合理的智能算法,既要考慮搜索性能,也要合理規避陷入局部最優。爲了更好的應對這種NP-難問題,尋找更好的次優解是咱們解決問題的關鍵。
動態公交VRP問題,有它獨特的限制要求(車載量限制、用戶時間窗限制、站點順序限制等等),這種狀況下一個合理的初始解很重要,可以較大程度上縮減搜索規模,這裏咱們能夠結合拼單邏輯,啓發式生成初始解;搜索過程當中引入禁忌表避免重複操做;採用變領域搜索避免陷入局部最優等等,在集中性和疏散性之間達到較好的平衡。另外,目標函數決定了搜索的方向,如何設計合理的目標函數,如何平衡拼單率和體驗之間的關係,一直是咱們探索的方向。目前咱們也在佈局經過機器學習智能推薦合理站點、引導車輛合理分佈等供需自動平衡方案。同時咱們也在利用已有的歷史訂單數據和用戶行爲數據經過深度學習的方法積極搭建咱們的仿真系統,爲針對不一樣運營區域獨立建模搭建基礎。
出於賦能公交行業的目的, 除支持滴滴主app呼單外,咱們還提供一個開放平臺合做模式,依靠開放平臺客戶能夠更加自主化的實現自身需求。
公交是一個多方合做的業務,技術平臺以開放平臺的模式來構建。使用開放api的方式,支持了多種方式的合做可能,運營方能夠直接在滴滴app上運營產品,也能夠經過咱們提供的開放api和sdk接入到自有系統和app產品運營。
目前咱們的產品和系統還有不少不完善的地方,也面對着不少的技術難點,歡迎你們對咱們提出您寶貴的意見,幫助咱們更好的成長,謝謝。
夢在遠方,路在腳下,咱們致力於爲您提供最佳公共出行解決方案!
2016年加入滴滴,創新公交負責人,主要負責動態公交總體業務架構設計。
2018年加入滴滴,主要負責創新公交乘客端後端、開放平臺和仿真平臺等工做。
2016年加入滴滴,主要負責動態公交的司機端後端和規劃引擎等工做。
2019年加入滴滴,主要負責動態公交規劃引擎和可視化平臺等工做。
滴滴地圖與公交事業部創新公交團隊,依託滴滴地圖導航技術和基礎數據能力,使用機器學習和智能優化方法等技術,致力於爲用戶提供靈活、高效的公共出行解決方案。
團隊長期招聘研發工程師,包括前端、後端、引擎策略等方向,歡迎有興趣的小夥伴加入,可投遞簡歷至 diditech@didiglobal.com,郵件請郵件主題請命名爲「姓名-應聘部門-應聘方向」。
內容編輯 | Charlotte
聯繫咱們 | DiDiTech@didiglobal.com
滴滴技術 出品