本篇文章通過對高德地圖的紅綠燈倒計時提示，引發作者對此方案設計的猜測。作者以方案分析、功能梳理兩個方面為主要論述內容，分析他對其的思考猜測，希望能對你有所幫助。

作為一個產品經理，尤其是有好奇心的產品經理，分析拆解已發布的產品功能是必不可少的事兒。

而最近對高德紅綠燈預測的方案分析就是其中之一。

一、起因

一天下午和我們的技術同學一同出差，路上在十字路口等著漫長的紅燈讀秒。而此時高德導航上也在顯示紅綠燈倒計時，第一反應是這個功能有意思且有用，解決因前方大車遮擋而看不到紅綠燈的問題能提高通行效率（可以讓司機提前準備駕駛，從抖音、朋友圈的娛樂中回到駕駛中）。

我在感嘆這個功能不錯同時，也在想它是如何實現。

而我們的技術同學強烈表示這是個硬件方案，要不咋能這么準確哪？

雖然在接下來的路口我們認真核對APP倒計時和燈桿上倒計時的差距，大概有2到3秒的誤差。但是其仍認為是硬件的IOT方案，在保持沒有深入思考就沒有發言權的原則同時，我選擇回來想想到底要如實現。

二、方案分析

1. 硬件IOT方案

如果想知道是不是硬件IOT方案，首先要想：如果是這個方案，那么需要和誰合作？有什么成本？

• 合作方：需要和各個地方的交管部門合作，同時涉及到硬件的采買、定制改造、安裝等，而且紅綠燈的硬件和家用燈硬件標準不同。紅綠燈需要在高溫、大雨等各種惡劣環境都能長時間正常運行，而家用燈很多時候根本無需考慮雨雪高溫等情況。那么這個硬件成本的上升和各種合規測試，由誰來負責？
• 成本：除了我們上面的說的硬件本身，還有后續的安裝等成本，還有一條潛在成本：如何協調各個地方的交管部門在同一個時間前，都能上線？這個成本是無形的，但是很大，如果大家做過To B業務就能夠理解。就比方你在公司內部做一個跨部門的合作，都不一定能順暢，那么跨地域、跨部門哪？畢竟高德的紅綠燈預測在上線初期就有了好幾十個城市，和這些城市的幾萬個核心路口。

通過以上看，硬件IOT的方案是理論上可行，但是成本太大，大概率不會是這個方案。

2. 平臺接入

如果有硬件且需要多方協調的成本如此大，是否可以純軟件平臺介入哪？比如直接拿各個地方交管平臺的數據哪？

我理解這個也不行，除了數據安全的角度外，最大的一個悖論是：如果我拿到了交管平臺的數據，我為啥不把所有路口的倒計時都做了哪？為啥只有一部分路口數據，而另一部分沒有哪？

因為從交管平臺的角度看，各個紅路燈的倒計時數據是沒有本質差別的。

而這個矛盾點的存在，證明現有的方案也不是交管平臺接入。

3. 數據挖掘

如果既不是硬件也不是平臺，還能是什么？大數據挖掘。這個方案的好處是：

• 不依賴公司外部，只需要組織（項目組）內部協調，周期自控。
• 現有的核心數據在移動端都可以獲得，且DAU足夠大，畢竟國內導航top2就是百度和高德。
• 針對路口車流量數據（數量、質量、置信度等）來區分是否需要挖掘該位置信息，非核心路口的車流量小，那么對應數據就少，經過數據清洗后可用的數據、能提高/達到的置信度都會比較難，所以才導致車流量小的非核心路口，沒有上線該能力。

三、功能梳理

我們分析完，發現最可能得是組織內部的純軟件方案， 那么結合一個case，我們嘗試梳理下需要哪些數據，及如何實現。

我們以一個十字路口要識別直行的紅燈、綠燈時長為例子來考慮。

基于如上的信息，先看司機是否在導航中，再看要識別的這個路口是否在用戶當前的規劃路線中。如果是，我們再看當前車輛在紅綠燈前后的表現，也就是關注速度的變化。

當考慮如下圖的一個十字路口時，我們先看不同車道的通行限制。其中只有中間車道可以直行，所以可以忽略后續左轉和右轉的車輛，僅僅看那些車輛從當前俯視圖路口的左側到達了右側。

比如圖中的轎車和跑車的行駛數據，而其中右轉的皮卡則無需關注，因為他的數據對當前直行紅綠燈時間判斷幾乎沒有影響。

然后再看不同車輛在這個路口附近（附近這個概念可以是上一個路口到這個路口，或者限定多遠的距離內，或者兩者結合取最小值）速度的變化。

如果我們以當前路口為例，將一天內各個時段經過該路口的不同車輛速度都畫在一個二維坐標系中，會是怎么樣哪？

我們以三臺車和一個紅綠燈周期為例子還嘗試畫出來：

因為不同車輛在到達該紅綠燈附近的速度不同，而且在該紅綠燈前方停止的車輛數量不同，會導致其剎車時的加速度不同。也就是影響了曲線斜率（為了簡單，假設加速度都是線性變化），同時會導致其停止的時間不同。

如果考慮這三輛車的速度變化，綠色停的最晚、起步也最晚；而紅色停的最早，起步也最早。

大概率是紅色排在第一，藍色第二，綠色第三，而他們三個的停車時長所占用的是時間段，就是該紅綠燈的紅燈時段。

我們可以把這個例子再擴充下，考慮兩輛車遇到紅綠燈需要停車再起步，另一輛車遇到綠燈直接開過去的情況。

紅車和綠車符合剛才說的規律，在其起步并且速度起來后的時段中，藍色車以一定速度駛入，并且做了減速（過路口一般要減速），然后在提速。

那么可以看到在藍色車的這個時間段內就是緊接著剛才紅燈時段的綠燈時段，然后再會進入下一個紅綠燈時段的循環。

再接著如上的例子，我們將右轉擴展為右轉加直行，那么這種情況會比剛才復雜。當直行紅燈時，在最右側車道上需直行的車輛依然會停車，從速度減為零，再從零起步這個過程與剛才類似。

但是如果此時是綠燈，一部分行人和電瓶車的直行導致右轉車輛停車等待，而此時在右側車道要直行的車輛，必然也需要等待。

如圖中需要直行的藍色車輛和需要右轉的灰色車輛（用對應顏色線表示其即將走的軌跡），此時與已經直行的車輛數據要如何處理？

筆者大膽猜測，當有一定數量的直行數據時候，這部分為零的數據，可以不要?；蛘呶覀兛紤]使用該數據，但是需要如下思考：

• 司機是理性人，當中間車道沒有車或者車輛明顯少于右側車道時，其不會駛入右側車道來直行。所以司機在右側車道直行時，中間車道的直行車輛必然多于右側車道的直行車。
• 而考慮到數據的置信區間，當數據通過多次累計后，便可以知道紅燈時長。如圖，藍色車輛速度為0的時間明顯更長，但是在多次數據積累下，還是可以確信紅色和綠色車輛的零速時間段為紅燈時間段。

上面所有信息都沒有基于導航的地理位置數據來分析，如果考慮可以精確到車道級別的數據來分析，就回更加簡單。

比如剛才右側車道允許直行的例子就好處理，可以將所有右側車道的數據單獨處理，或者作為輔助判斷即可，也可以用同一個時刻右轉車輛的等待時間結合起來計算。

相對簡單的辦法就是用中間直行車道數據來計算，因為數據量足夠大，所以暫時剔除一部分應該對預測準確性影響不大。

當一個簡單情況分析后（類似我們學數學的特例），我們再擴展條件，比如上文提到的右轉車道上允許直行。

在考慮這個擴展后，我們還可以考慮如下更多因素：

• 考慮N天的同一時段的數據，紅綠燈循環有穩定性的周期性，再結合工作日和休息日考慮（有部分紅綠燈在休息日是黃燈閃爍）。
• 考慮天氣異常對車輛行駛速度的影響。
• 考慮司機臨時改變路線（可能是開錯了數據如何處理）。
• 在考慮非導航內數據如何使用（此處可以截個行車軌跡圖，高德有的）。

當模型已經有了一個版本，如何更新迭代？

此時建立一個數據模型循環飛輪即可。筆者認為該功能在最初上線前，除了通過原始數據中部分未參與模型訓練數據進行模式測試，同時可結合實際線上的、實時的車輛行駛數據進行測試。

• 比如模型預測該紅綠燈現在司機需要停車，當然此時用戶側無感知，然后看車輛接下來的速度變化是否符合預期。
• 比如模型預測該司機保持現有速度可以綠波通過接下來的四個紅綠燈，但是在第三個卻停車，這便不符合預期，那就結合前段時間（天）該路口的數據從新分析。
• 比如模型預測該司機此時可以行駛過該路口但是卻停下來了，而且接下來的周期中經常出現該情況，就要考慮是否此處紅燈時間或者周期已經進行調整，然后從新更改模型。

四、寫在最后

以上的分析都是站在廚房門外，聞著味道猜測做了什么菜、怎么做的菜。如果有讀者知道菜譜，還望聯系分享。