本篇文章通过对高德地图的红绿灯倒计时提示，引发作者对此方案设计的猜测。作者以方案分析、功能梳理两个方面为主要论述内容，分析他对其的思考猜测，希望能对你有所帮助。
作为一个产品经理，尤其是有好奇心的产品经理，分析拆解已发布的产品功能是必不可少的事儿。
【资料图】
而最近对高德红绿灯预测的方案分析就是其中之一。
一、起因
一天下午和我们的技术同学一同出差，路上在十字路口等着漫长的红灯读秒。而此时高德导航上也在显示红绿灯倒计时，第一反应是这个功能有意思且有用，解决因前方大车遮挡而看不到红绿灯的问题能提高通行效率（可以让司机提前准备驾驶，从抖音、朋友圈的娱乐中回到驾驶中）。
我在感叹这个功能不错同时，也在想它是如何实现。
而我们的技术同学强烈表示这是个硬件方案，要不咋能这么准确哪？
虽然在接下来的路口我们认真核对APP倒计时和灯杆上倒计时的差距，大概有2到3秒的误差。但是其仍认为是硬件的IOT方案，在保持没有深入思考就没有发言权的原则同时，我选择回来想想到底要如实现。
二、方案分析
1. 硬件IOT方案
如果想知道是不是硬件IOT方案，首先要想：如果是这个方案，那么需要和谁合作？有什么成本？
合作方：需要和各个地方的交管部门合作，同时涉及到硬件的采买、定制改造、安装等，而且红绿灯的硬件和家用灯硬件标准不同。红绿灯需要在高温、大雨等各种恶劣环境都能长时间正常运行，而家用灯很多时候根本无需考虑雨雪高温等情况。那么这个硬件成本的上升和各种合规测试，由谁来负责？成本：除了我们上面的说的硬件本身，还有后续的安装等成本，还有一条潜在成本：如何协调各个地方的交管部门在同一个时间前，都能上线？这个成本是无形的，但是很大，如果大家做过To B业务就能够理解。就比方你在公司内部做一个跨部门的合作，都不一定能顺畅，那么跨地域、跨部门哪？毕竟高德的红绿灯预测在上线初期就有了好几十个城市，和这些城市的几万个核心路口。
通过以上看，硬件IOT的方案是理论上可行，但是成本太大，大概率不会是这个方案。
2. 平台接入
如果有硬件且需要多方协调的成本如此大，是否可以纯软件平台介入哪？比如直接拿各个地方交管平台的数据哪？
我理解这个也不行，除了数据安全的角度外，最大的一个悖论是：如果我拿到了交管平台的数据，我为啥不把所有路口的倒计时都做了哪？为啥只有一部分路口数据，而另一部分没有哪？
因为从交管平台的角度看，各个红路灯的倒计时数据是没有本质差别的。
而这个矛盾点的存在，证明现有的方案也不是交管平台接入。
3. 数据挖掘
如果既不是硬件也不是平台，还能是什么？大数据挖掘。这个方案的好处是：
不依赖公司外部，只需要组织（项目组）内部协调，周期自控。现有的核心数据在移动端都可以获得，且DAU足够大，毕竟国内导航top2就是百度和高德。针对路口车流量数据（数量、质量、置信度等）来区分是否需要挖掘该位置信息，非核心路口的车流量小，那么对应数据就少，经过数据清洗后可用的数据、能提高/达到的置信度都会比较难，所以才导致车流量小的非核心路口，没有上线该能力。
三、功能梳理
我们分析完，发现最可能得是组织内部的纯软件方案， 那么结合一个case，我们尝试梳理下需要哪些数据，及如何实现。
我们以一个十字路口要识别直行的红灯、绿灯时长为例子来考虑。
基于如上的信息，先看司机是否在导航中，再看要识别的这个路口是否在用户当前的规划路线中。如果是，我们再看当前车辆在红绿灯前后的表现，也就是关注速度的变化。
当考虑如下图的一个十字路口时，我们先看不同车道的通行限制。其中只有中间车道可以直行，所以可以忽略后续左转和右转的车辆，仅仅看那些车辆从当前俯视图路口的左侧到达了右侧。
比如图中的轿车和跑车的行驶数据，而其中右转的皮卡则无需关注，因为他的数据对当前直行红绿灯时间判断几乎没有影响。
然后再看不同车辆在这个路口附近（附近这个概念可以是上一个路口到这个路口，或者限定多远的距离内，或者两者结合取最小值）速度的变化。
如果我们以当前路口为例，将一天内各个时段经过该路口的不同车辆速度都画在一个二维坐标系中，会是怎么样哪？
我们以三台车和一个红绿灯周期为例子还尝试画出来：
因为不同车辆在到达该红绿灯附近的速度不同，而且在该红绿灯前方停止的车辆数量不同，会导致其刹车时的加速度不同。也就是影响了曲线斜率（为了简单，假设加速度都是线性变化），同时会导致其停止的时间不同。
如果考虑这三辆车的速度变化，绿色停的最晚、起步也最晚；而红色停的最早，起步也最早。
大概率是红色排在第一，蓝色第二，绿色第三，而他们三个的停车时长所占用的是时间段，就是该红绿灯的红灯时段。
我们可以把这个例子再扩充下，考虑两辆车遇到红绿灯需要停车再起步，另一辆车遇到绿灯直接开过去的情况。
红车和绿车符合刚才说的规律，在其起步并且速度起来后的时段中，蓝色车以一定速度驶入，并且做了减速（过路口一般要减速），然后在提速。
那么可以看到在蓝色车的这个时间段内就是紧接着刚才红灯时段的绿灯时段，然后再会进入下一个红绿灯时段的循环。
再接着如上的例子，我们将右转扩展为右转加直行，那么这种情况会比刚才复杂。当直行红灯时，在最右侧车道上需直行的车辆依然会停车，从速度减为零，再从零起步这个过程与刚才类似。
但是如果此时是绿灯，一部分行人和电瓶车的直行导致右转车辆停车等待，而此时在右侧车道要直行的车辆，必然也需要等待。
如图中需要直行的蓝色车辆和需要右转的灰色车辆（用对应颜色线表示其即将走的轨迹），此时与已经直行的车辆数据要如何处理？
笔者大胆猜测，当有一定数量的直行数据时候，这部分为零的数据，可以不要。或者我们考虑使用该数据，但是需要如下思考：
司机是理性人，当中间车道没有车或者车辆明显少于右侧车道时，其不会驶入右侧车道来直行。所以司机在右侧车道直行时，中间车道的直行车辆必然多于右侧车道的直行车。而考虑到数据的置信区间，当数据通过多次累计后，便可以知道红灯时长。如图，蓝色车辆速度为0的时间明显更长，但是在多次数据积累下，还是可以确信红色和绿色车辆的零速时间段为红灯时间段。
上面所有信息都没有基于导航的地理位置数据来分析，如果考虑可以精确到车道级别的数据来分析，就回更加简单。
比如刚才右侧车道允许直行的例子就好处理，可以将所有右侧车道的数据单独处理，或者作为辅助判断即可，也可以用同一个时刻右转车辆的等待时间结合起来计算。
相对简单的办法就是用中间直行车道数据来计算，因为数据量足够大，所以暂时剔除一部分应该对预测准确性影响不大。
当一个简单情况分析后（类似我们学数学的特例），我们再扩展条件，比如上文提到的右转车道上允许直行。
在考虑这个扩展后，我们还可以考虑如下更多因素：
考虑N天的同一时段的数据，红绿灯循环有稳定性的周期性，再结合工作日和休息日考虑（有部分红绿灯在休息日是黄灯闪烁）。考虑天气异常对车辆行驶速度的影响。考虑司机临时改变路线（可能是开错了数据如何处理）。在考虑非导航内数据如何使用（此处可以截个行车轨迹图，高德有的）。
当模型已经有了一个版本，如何更新迭代？
此时建立一个数据模型循环飞轮即可。笔者认为该功能在最初上线前，除了通过原始数据中部分未参与模型训练数据进行模式测试，同时可结合实际线上的、实时的车辆行驶数据进行测试。
比如模型预测该红绿灯现在司机需要停车，当然此时用户侧无感知，然后看车辆接下来的速度变化是否符合预期。比如模型预测该司机保持现有速度可以绿波通过接下来的四个红绿灯，但是在第三个却停车，这便不符合预期，那就结合前段时间（天）该路口的数据从新分析。比如模型预测该司机此时可以行驶过该路口但是却停下来了，而且接下来的周期中经常出现该情况，就要考虑是否此处红灯时间或者周期已经进行调整，然后从新更改模型。
四、写在最后
专栏作家
代成龙，人人都是产品经理专栏作家，智能硬件创业公司产品狗，从视频巨头公司到玩智能硬件的公司，继续产品设计工作。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
关键词：
