这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
运营和执法是两个部门、两套诉求，但共用一批前端设备，数据口径经常混用
视频流量检测受光照、天气、遮挡影响大，夜间和雨雪天数据不可用
信号配时调整后效果好不好，没有基线数据就没法验证
拥堵是个主观感受，怎么用数据说清「这段路确实变堵了」
项目背景：同一批摄像头，两本账
城市里的交通摄像头，通常由交警部门建设，主要用途是执法：闯红灯、超速、违停、不按导向车道行驶。
当运营部门想用这批数据做交通分析时，会遇到一个根本性的错位：
| 对比项 | 执法视角 | 运营视角 |
|---|---|---|
| 关心什么 | 有没有违法 | 通行顺不顺畅 |
| 数据粒度 | 精确到车牌、精确到帧 | 按车道按周期的流量数 |
| 准确率要求 | 证据级，不能错 | 统计级，允许误差 |
| 时间要求 | 事后取证即可 | 需要实时 |
| 数据完整性 | 只记录违法车辆 | 需要全部车辆 |
最后一行是关键：**执法系统只记录违法车辆，不记录所有车辆。** 拿违法数据算流量，算出来的是「违法率」不是「交通量」，完全不能用。
所以运营平台的第一件事，是建立**独立于执法的流量采集体系**。
第一件事：流量数据从哪来
流量采集有四种主流手段，各有各的适用场景和短板：
| 方式 | 原理 | 优点 | 短板 |
|---|---|---|---|
| 视频检测 | 图像识别车辆并跟踪 | 复用现有摄像头，信息丰富 | 受光照天气影响，夜间和雨雪天差 |
| 毫米波雷达 | 多普勒测速与目标检测 | 全天候，不受光照影响 | 成本较高，对静止目标不敏感 |
| 地磁/线圈 | 车辆通过引起磁场/电感变化 | 准确稳定，成本低 | 只能测流量和占有，不能分类 |
| 导航数据 | 手机定位轨迹聚合 | 覆盖全路网，成本低 | 只有浮动车样本，不代表全部车辆 |
项目的选型是**分层组合**：
- **主要路口**：视频 + 雷达组合。视频做车型分类和排队长度，雷达做全天候流量兜底。
- **次要路口和路段**：地磁或视频单独使用，控制成本。
- **全路网态势**：接入导航数据做宏观补充，弥补固定检测器的覆盖空白。
为什么不全用视频？因为**夜间和雨雪天的数据质量会断崖式下降**。而交通分析恰恰很需要夜间数据——货车通行、夜间施工、凌晨的异常拥堵，都发生在光照最差的时段。
为什么不全用导航数据？因为导航数据是**抽样**的。它反映的是装了导航 App 的那部分车辆，通常是小客车为主，货车覆盖很差。用导航数据算总流量，会系统性低估。
导航数据要和固定检测器做定期校准：在同时有两者数据的路段，比较导航推算流量和实际检测流量，得出修正系数。不同路段、不同时段的系数不一样，不能用统一值。
第二件事：拥堵怎么用数据说清
「这段路很堵」是主观感受。要变成可管理的东西，得拆成几个可测的量：
| 指标 | 定义 | 用途 |
|---|---|---|
| 平均行程时间 | 通过某路段所需时间 | 最直观，市民能感知 |
| 延误 | 实际时间 − 自由流时间 | 衡量拥堵程度 |
| 排队长度 | 红灯期间车辆排队距离 | 判断是否溢出到上游路口 |
| 饱和度 | 实际流量 ÷ 通行能力 | 判断路口是否超负荷 |
| 停车次数 | 通过路段被停下的次数 | 衡量行驶连续性 |
「排队长度」和「饱和度」是两个最实用的指标，因为它们能直接指导动作。
排队长度超过路段长度，就意味着**溢流**——车排到了上游路口，把上游路口也堵死了。这种情况必须立刻干预，否则会连锁反应。系统对溢流单独设了报警。
饱和度超过 0.9，说明这个路口已经接近通行能力上限，再怎么优化配时也解决不了，需要渠化改造或分流。**这个判断能帮管理部门避免在无效的地方反复调参数。**
拥堵要能定位到具体原因
报「XX 路拥堵」没意义，要说清是什么造成的：
- **常发性拥堵**：每天同一时段都堵，说明通行能力不足或配时不合理。
- **偶发性拥堵**：平时不堵突然堵了，多半是事故、施工、恶劣天气。
- **溢流型拥堵**：下游路口排队溢出，导致上游堵。处理要在下游。
- **交织型拥堵**：出入口、匝道汇入导致，需要渠化或信号控制。
四种类型的处置方式完全不同。**不做这个分类，所有拥堵都用「优化配时」去解，大部分会失败。**
第三件事：配时优化，先有基线才能谈优化
信号配时是交通运营里最核心也最容易做假的一环。
「我们优化了 30 个路口的配时，通行效率提升 15%」——这句话怎么验证？如果没有优化前的基线数据，这个 15% 就是编的。
所以项目的第一步不是调参数，是**积累基线**：
- 1选定要优化的路口，连续采集 2 到 4 周的流量、延误、排队数据。
- 2覆盖工作日和周末、早高峰和平峰、晴天和雨天。
- 3算出每个时段的关键指标均值，作为基线。
- 4优化后再采集同样时长的数据，同口径对比。
「同口径」三个字很重要。**优化后如果正好碰上放假或者下雨，数据本来就会变好，不能算作优化效果。** 所以对比要选天气、日期类型相近的日子。
配时方案怎么定
基本思路是按流量分配绿灯时间。一个周期内，各方向的绿灯时长应该和它的流量占比大致对应：
| 时段 | 周期时长 | 策略 |
|---|---|---|
| 早高峰 | 较长（如 140 秒） | 主通勤方向加长绿灯 |
| 平峰 | 中等（如 100 秒） | 均衡分配 |
| 晚高峰 | 较长 | 反向通勤方向加长 |
| 夜间 | 短（如 60 秒） | 缩短周期，减少空放 |
夜间为什么要缩短周期？因为流量小，如果还用 140 秒周期，红灯等待时间很长，而实际没有车通过。**缩短周期能让车辆少等，同时减少「空放」——绿灯亮着但没有车通过。**
「空放」这个指标值得单独监测。绿灯时间里没有车通过，就是浪费。空放率高的方向，绿灯该缩短。
「感应控制」和「自适应控制」听起来更高级，但前提是有可靠的车检器。**如果检测器本身不准，自适应控制会比定时控制更糟**——它会基于错误数据频繁调整，造成路口节奏混乱。所以先保证检测数据可信，再谈自适应。
第四件事：事件检测，要能区分「堵」和「停」
交通事件检测包括：事故、抛锚、逆行、行人闯入、抛洒物、拥堵。技术上都是「发现异常」，但误报率差别很大。
最容易误报的是**事故和抛锚**。一辆车停在路边，可能是事故，可能是违停，可能是等客，可能是临时装卸货。单靠视频很难区分。
项目用的判断组合是：
- **停留时长**。超过 3 分钟且位置不变，进入待确认。
- **是否在车道内**。停在行车道内比停在路边严重得多。
- **是否影响通行**。后方车辆是否出现减速、变道绕行。
- **是否有人员下车**。有人下车走动，事故概率明显上升。
- **双闪灯状态**。能识别的话，是重要辅助信号。
五个条件里，「是否影响通行」是最有价值的。**一辆车停在车道内但后方没有车绕行，可能只是临时停靠；一旦后方开始变道，就是真事件。**
这套组合判断能把误报压下来，但不可能消除。所以设计上保留了**人工确认环节**：系统报「疑似事件」，由监控中心人员看视频确认后，才转为正式事件并派警。
直接把疑似事件推给路面警力，是最糟糕的设计——出警十次九次是误报，警力很快就会不响应。
几条可以带走的判断
- **执法数据不能当流量数据用。** 执法只记录违法车辆，拿它算流量算出来的是违法率。
- **流量采集要分层组合。** 主路口视频加雷达、次路口地磁、全路网导航补充，不能只靠一种。
- **导航数据是抽样，必须与检测器校准。** 不同路段时段的修正系数不一样。
- **拥堵要能分类。** 常发、偶发、溢流、交织，四种处置方式完全不同，都拿配时去解一定失败。
- **排队溢出要单独报警。** 溢流会把上游路口一起堵死，必须立刻干预。
- **饱和度超过 0.9 的路口，调配时没用。** 该做渠化改造或分流，别在无效的地方反复调参。
- **配时优化必须先有基线。** 没有优化前的同口径数据，「提升 15%」都是编的。
- **检测器不准时不要上自适应。** 基于错误数据的自适应控制比定时控制更糟。
- **事件检测要保留人工确认。** 疑似事件直接派警，警力很快就会不响应。
用到的技术
这些技术在其他项目里也用过，完整的协议支持清单和已实测规模见技术能力
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。