行业解决方案

交通数字孪生:把一条路网搬进一块三维屏里

交通数字孪生平台简介

交通数字孪生这词听着有点玄,落到我们实际做过的项目里,无非是把一条路、一个路口、一段快速路按实际尺寸搬进三维场景,再把卡口、雷达、信号机、车载 GPS 的数据挂到对应的模型上。值班的人不用在十几个系统之间来回切,一块屏就能看到车在哪个位置、灯什么状态、哪个方向开始排队。

现在的交通监控,看得见却用不上

大部分城市的交通数据其实不缺。卡口在公安手里,电警归交警,线圈和地磁是建设口装的,公交 GPS 在公交公司,网约车和货车轨迹又在平台方那儿。数据都有,问题是各看各的:视频里能看到车排到了路口中间,但你说不清队尾具体在第几个车位,也说不清再等两个周期会不会回溢到上一个路口。

三维场景的价值就在这一步。二维地图上一个红点代表拥堵,三维里能看出是左转待转区压了车,还是直行道被违停占掉一条。判断不一样,处置的办法也就不同。这块如果只做二维,说实话,值班员用两周就回去了。

智慧交通数字孪生的平台架构:一个底座,三张图

我们习惯把整套东西拆成三层,布署和验收都按这三层来对。

  • 静态底座:路网、路口、渠化、建筑、绿化、天桥、隧道,按 CAD 图纸加航拍加街景建模,标线宽度、车道数、导流岛位置都按实际尺寸来。
  • 动态数据层:雷视一体、地磁、卡口过车、浮动车 GPS、公交 GPS、信号机相位状态,统一做时间对齐。
  • 应用层:路网态势一张图、信控节点监控、交通仿真推演,三张图各管一件事,不硬凑在一个界面里。

这里有个容易被忽略的点:数据延迟。我们把整条链路压到 3 秒以内,超过 5 秒,屏幕上放的就不是现在,是历史。既使数据再全,值班员看一眼发现对不上实景,后面再准也没人信。

路网态势一张图

一张图上先看总量,再看结构。左上角是当日车流量,右侧按车型拆开,小车、大客车、特种车各占多少,一眼能看出这段路是客运为主还是货运为主。货运占比高的路段,坡道和匝道的纵坡设计、限速策略都得另外考虑。

交通数字孪生路网态势一张图
全域路网态势一张图:当日车流量 256,892 车次,车型结构与信控节点状态同屏显示

车流量这个数字单看没什么意义,得跟历史同期比。周一早高峰 25 万和周五晚高峰 25 万,是两个完全不一样的故事,前者是通勤刚性需求,后者里头掺了不少出城和货运。

拥堵研判:说清堵在哪、堵多久

拥堵指数我们按 0 到 10 分级,8 以上算严重,5 到 8 是中度,3 以下基本畅通。截图里高新大道东西向 8.2,建设路十字路口 5.6,绕城高速南段 2.1,三个数一摆,警力往哪调基本就定了。

指数只是结果,往下还得看三个过程量:排队长度、车均延误、路口饱和度。排队长度决定会不会回溢,车均延误决定市民体感,饱和度则说明这个路口还有没有余量。做推演的时候我们会把这三个量往后放 15 分钟,看看不加干预会烂成什么样,再决定是调配时还是直接派警。

信控节点:配时不是拍脑袋

平台上的信控节点一般显示三种状态:配时优化中、绿波带协调、紧急优先。截图里 A-01 在做配时优化,B-04 在跑绿波协调,C-09 触发了紧急优先,多半是救护车或者消防车要过路口。

要说清楚一点:平台只出方案,不直接改灯。配时下发要过审批,紧急优先更得跟支队走流程,这是现实。我们做的是把这个路口该放多少秒算清楚,附上仿真对比,让人签字的时候心里有底。有些项目上来就要求"一键下发",我们一般不接,出了事说不清。

绿波这块最考验基本功。相位差差 3 秒,带宽就掉一半;车速假设取 40 还是 50,效果完全两样。所以做绿波之前,先把路段自由流车速实测一遍,别拿设计车速去凑。

三维场景:路口、枢纽、快速路

场景精度按用途分。路口要看清渠化和慢行,斑马线、二次过街的等待区、公交进出站的位置都得做出来;快速路更关心车道级车流和货车占比,模型可以粗一些,但车道连续性和匝道分流必须准。

城市路口三维场景与慢行交通还原
路口三维场景:斑马线、行人等待区,公交与社会车辆混行

快速路那边反过来,车道可以简,但匝道分流点、限速标志、门架位置必须准,不然车辆像在自己开。车辆模型用低模加 LOD,一个标准十字路口控制在 8 到 15 万面,浏览器端能跑满 30 帧。做得太精细,打开就卡,值班室那台老机器第一个抗议。

效率与减排:数字要能解释

平均车速和碳减排是最容易被追问的两个指标。截图里平均车速 42 km/h,当日碳减排 1.2 吨。车速好说,线圈和雷达都能测;碳减排是估算,按怠速时间、启停次数和车型油耗模型折算出来。

我们的做法是把计算口径写在指标旁边,点开能看到假设条件。这东西适合做趋势对比,别拿去当碳交易凭证,不然早晚要挨骂。

数据接入与实施节奏

接口这块没什么花活。视频走 GB/T 28181,卡口过车走标准过车数据,信号机各家协议不一样,得挨个对接;浮动车和公交 GPS 一般走 HTTP 或者 MQTT 推送,量大的时候还要做一层削峰。

实施建议分三期,别一口气全上:

  • 一期:路网建模加态势一张图,先把"看得见"做扎实,两到三个月能出东西。
  • 二期:接信控,做节点监控和配时优化建议。这一期最费人,因为要跟信号机厂商一家一家磨协议。
  • 三期:上仿真推演,做预案评估,比如大型活动、施工占道、恶劣天气下的路网影响。

真正难的不是建模,是让几个厂商的数据对得上时间戳。同一辆车,卡口记一次、雷达记一次、GPS 又记一次,三条记录时间差两秒,轨迹就散了。这类问题没有捷径,只能一条一条捋。

适用场景

  • 城市路口:渠化改造前做方案比选,改完再回头看效果;
  • 快速路与高速:车道级流量监测、事故检测、匝道控制;
  • 客运枢纽:站前广场车流、出租车蓄车池、公交进出站秩序;
  • 物流园区:货车预约、装卸位调度,园区内部道路与外围干道联动。

交通数字孪生不是把路口做得越像越好,而是让每一个数字都能对应到具体的一条车道、一个相位、一辆车。做到这一步,值班员才会真的天天用它。

OUR CLIENT

我们的客户

做交通三维可视化这块,我们接过信号机、卡口和浮动车的数据,也踩过时间戳对不上的坑。

We build 3D visualization for urban intersections, expressways and transport hubs, and have integrated signal controllers, ANPR cameras and floating car data in real projects

  • 路口特种车辆与行人混行三维场景
  • 快速路车道级车流三维还原
  • 交通数字孪生路网态势与信控节点监控
  • 案例
  • 电话
  • 首页
  • 数字孪生
  • 返回顶部