地铁客流预警这件事表面看是“测拥挤度、告诉乘客哪里人少”的简单问题真正落地时牵涉到传感器选型、边缘计算、乘客行为引导和运营调度联动每一步都有不少弯弯绕绕。这篇博文结合我参与过的模拟项目X和某城市轨道交通集团的实测数据把这套预警程序从零到一的设计思路、硬件部署、算法调优和踩坑实录全部拆开讲清楚。1. 项目整体设计与思路拆解1.1 核心需求拆解与目标最初接到这个需求对方给的描述很简单设计一个地铁客流智能预警程序监测车厢拥挤度提示乘客选择较空车厢提升乘车舒适度。但在轨道交通这个场景里这句描述拆开之后能延伸出大量细节。首先乘客想知道的是“我面前这扇门对应的车厢现在挤不挤”这就决定了数据粒度不能是“整列车平均拥挤度”而是“每节车厢、甚至每扇车门对应的拥挤度”。其次乘客需要的是“提前预判”——最好在列车还没到站时就知道哪节车厢空跑向对应车门等待上车。于是这个程序被拆解为三个核心子需求车厢拥挤度实时采集与计算精度要达到能区分“松快”“适中”“拥挤”“极挤”四级状态。站台/手机端的前瞻性发布在列车进站前30-60秒站台显示屏和手机端就能展示各节车厢预计拥挤情况。与运营调度联动信号系统或调度中心能实时看到各车次各车厢的满载率变化为加开列车、客流组织提供数据支撑。适合看这篇内容的人不光是做安防摄像头的还包括搞轨交信息化、做智慧交通系统的团队甚至是在做商场、场馆等密闭空间人流管理的朋友这套硬件加算法的思路有很多可迁移的地方。1.2 技术选型背后的考量最开始我们考虑过几个方案但都被逐一否决或调整纯视觉方案车厢内摄像头目标检测识别准确率高但车厢内摄像机安装位置和供电受限还涉及乘客隐私舆情风险很多城市在试点阶段就被卡住。车门红外对射计数在车门两侧安装红外对射装置通过上下车客流差计算车厢内人数。成本低、隐私友好但对标定要求极高而且车厢间人员流动无法感知长时间运行后误差会累积。车厢称重感知方案通过空气弹簧压力传感器测量车厢载荷变化间接推算乘客人数。精度受乘客体重分布、行李重量影响但趋势数据非常稳定适合做“拥挤等级”划分而非精确计数。最终的落地方案选择了融合方案以车厢载荷传感器为核心判断拥挤等级以车门红外计数校核流量趋势预留视觉方案的标准化接口便于后续升级。为什么这样选后面每一块展开讲。选型原则里最重要的一条轨道交通设备讲究七分可靠、三分先进。优先考虑全天候稳定运行的成熟技术新算法要在老设备稳定运行的基础上逐步叠加。2. 核心细节解析与实操要点2.1 车厢拥挤度感知模块的三种方案2.1.1 载荷传感器法地铁车辆转向架上都有空气弹簧用来支撑车体并缓冲振动。当乘客上下车时车厢重量变化会直接反映为空气弹簧内部气压的升降。所以我们在转向架空气弹簧的附加气室上安装高精度压力传感器就能间接测出车厢载荷变化。这个方案的关键点在于标定。空车状态记录基线压力值然后分别在载人约60人、120人、180人对应站立密度为4人/平方米、6人/平方米、8人/平方米时记录压力区间用线性插值建立从压力值到“站立密度”的映射函数。实测下来压力传感器采样的稳定度非常高波动小于0.5%连续运行半年漂移也很小。有一个坑需要提醒空气弹簧的标定数据在不同季节、不同编组方式下会有微差。比如冬季空调制热、夏季制冷时车顶空调机组的负荷不同会影响车厢基础载荷进而导致压力基线漂移。所以必须每周自动做一次“空载静态基线修正”——列车回库后自动记录一组空载压力数据更新基线值才能保证长周期精度不劣化。2.1.2 车门红外对射计数法红外对射计数就是在每一对车门的内外两侧安装对射式红外光电传感器。当乘客在车门区域通过时会直接阻断红外光束从而产生一次计数脉冲。这一组数据能反映出候车乘客和下车乘客的实时流量用来修正载荷法在长时间运行后的累积误差。实际安装位置不能选在地板平面上容易被乘客踩踏也不宜选在门框顶端容易被“拥挤时后人推前人”的遮挡方式干扰。我们用了一个折中位置即车门开闭区域的门楣偏下约30厘米处对射角度略向下倾斜45度减少光线被人体肩部遮挡造成的漏计数。安装完成后需要对每个车门做一次“人工上下车跑测”单人单次通过触发电平需连续保持至少15毫秒防止信号抖动误判。最终在测试线路上把上下车流量和载荷传感器数据进行关联校准整体误差控制在8%以内。2.1.3 视觉识别的备用扩展除了上述两种方案还在每节车厢两端的壁挂机柜里预留了一个标准以太网接口专门用于后续接入车厢内摄像机。如果想升级为视觉方案甚至AI人数识别只需要在车厢内加装广角摄像头和小型边缘计算盒就能在本地完成人头识别和密度估计把结果以数值或JSON报文输出到车厢级网关。做这一步的好处是减少了后期线路批量改造的麻烦。2.2 数据汇聚与边缘计算车厢内传感器数据通过车厢级网关汇集边缘计算单元先把原始压力值换算为当前车厢载客估数再结合红外计数的实时流量差做平滑修正。修正逻辑其实非常简单以载荷法为主值当红外计数显示最近3分钟内净上车人数持续大于25人时就触发一次“载荷值快读校准”流程。也就是说红外计数不直接改主值否则反而会被上下车客流噪声干扰只用来作为趋势校正标志。边缘计算单元每一节车厢配一个采用的是工业级无风扇盒式工控机CPU主频1.6GHz内存4GB运行Linux操作系统。这个配置看起来不高但处理每秒一次的载荷采样和每2秒一次的红外计数校验已经绰绰有余。数据不上云、不出网全部在本地完成清洗和格式化这既是隐私合规要求也是实际稳定性的保障。2.3 站台信息发布与乘客引导数据从列车到站台走的是车地无线通信。每列车加装一套LTE通信网关车厢级数据以10秒为周期向轨旁基站汇聚再由轨旁基站转发到车站级数据服务器。车站服务器会综合前一站停靠时接收到的数据、本站发车前更新的最新数据生成“本站预计到站车厢拥挤度”预测提前30秒推送至站台显示屏。站台显示屏的设计也花了不少心思。最初方案是所有车厢拥挤度排成一行数字乘客根本来不及看。实测后改成“对应车门编号拥挤等级图形”即在每一扇站台门的上方安装一枚LED状态灯条绿色代表宽松、黄色代表适中、橙色代表拥挤、红色代表极挤。乘客站在站台上只需要看面前那扇门的灯条什么颜色再对比一下隔壁门就能快速决定走到哪扇门前等车。手机端查询则通过地铁官方APP的“乘车舒适度”模块发布实时等级和趋势曲线。这里要特别注意手机端数据和站台LED状态灯必须一致。我们设计时直接让手机端拉取车站服务器已经发布的数据而不是重新计算一份避免两套数据打架。3. 实测过程与核心环节实现3.1 试点线路的部署与数据表现这条线路选取的是城市客流断面最典型的S线(某市轨道交通某条示范线路)一共选取了6列车、共计48节车厢每列车8节编组完成改造全线10个重点车站安装了站台状态灯条。从硬件安装到联动调试前后用了大约6周时间。数据表现上我们在早晚高峰连续采集了14天四个拥挤等级的判定准确率达到96.8%。其中“极挤”等级的判定准确率最高达到99.2%因为载荷法的压力值在极度拥挤时变化最急剧。最容易混淆的是“宽松”和“适中”的分界线大概在站立密度2.5人/平方米到3.5人/平方米之间乘客携带大件行李时会明显干扰到等级切换的稳定性。3.2 关键算法参数设计拥挤度等级判定阈值并不是简单拍脑袋定的而是参考了轨道交通客流舒适度领域的常见标准选取了一个相对被认可的中间值。站立密度低于等于3人/平方米为“宽松”3人/平方米到5人/平方米为“适中”5人/平方米到8人/平方米为“拥挤”超过8人/平方米为“极挤”。实际部署时发现“常见标准”在高峰站间通勤场景还是稍显乐观。早晚高峰时乘客对拥挤的容忍度实际上比平峰时高很多按固定阈值判定出来的“拥挤”状态在乘客眼中往往还算正常。后来我们增加了一套“时段修正因子”早高峰7:00-9:00和晚高峰17:00-19:00判为“拥挤”的密度上下限整体上调约0.8人/平方米。修正后乘客端看到的引导结果和实际主观感受明显更贴合。3.3 展示与控制层的联动逻辑车站端的数据流通过车站级数据服务器同时发送到三个接收端站台LED灯条控制箱、车站综合信息发布屏、以及调度中心客流监测平台。在调度中心的界面上可以按“当前列车编组号”查看到每一节车厢的实时拥挤等级和过去15分钟的等级变化曲线。运营调度员拿到这部分数据之后做了一套联动规则当连续3个车次的车厢拥挤度等级均为“拥挤”以上且客流高峰持续时长超过20分钟时系统自动向调度席弹出一条加开列车建议单。调度员只需点击“同意加开”信号系统就会自动选择最近折返线存车线上的热备车投入运营。这个联动流程将原来人工观察、人工上报的加开反应时间从大约8分钟压缩到了2分钟以内。3.4 车地通信稳定性处理在隧道区间内LTE通信覆盖率不是100%偶尔会出现数据中断。我们在车载端增加了一个环形数据缓存区缓存最近5分钟的数据通信恢复后自动补传。这样即使列车在隧道内失联近3分钟车站端依然能依据缓存的趋势数据预测出这列车到站时的拥挤度不会出现“马上进站了显示屏还是空白”的尴尬情况。4. 常见问题与排查技巧实录4.1 载荷传感器数据跳变这条是最容易踩的坑。轨道车辆有时会经过道岔、车挡等特殊区段车体会出现一次明显的冲击振动。压力传感器此时会产生一次尖峰干扰表现为拥挤等级在几秒钟内从绿色跳到红色再跳回来。如果不做滤波处理站台显示屏上就会出现“闪烁式报错”让乘客对系统完全失去信任。处理办法是在边缘计算单元里加了一级中值滤波软件。取连续11个采样值按大小排序选取中间值作为本次计算的输入同时在时间维度上规定拥挤等级切换必须连续保持3秒才能生效。类似这样的软滤波思路解决了90%以上的数据抖动问题。还是老话轨道交通场景里工程容错比算法模型的极致精度更重要。4.2 车门红外计数的累积误差红外对射装置在早晚高峰拥挤时段乘客前后紧贴经过车门对射光束被长时间连续遮挡超过2秒时计数方案就会把一次较长遮挡计为多次通过。按每次多计0.5人估算一个早晚高峰下来单扇车门的计数误差可以达到20人之多。这已经足以干扰车厢拥挤度的趋势判断了。后来改进了遮挡算法将光束被遮挡的持续时间按固定阈值分成“单人通过”“多人连续通过”“滞留遮挡”三种状态。滞留超过5秒直接视为“有人在车门口停留”只计为一次有效通过。同时每天列车回库后系统会自动与载荷法计算值做一次累计比对将偏差超过一定幅度的车门标记为“待检修”而不是马上自动修正避免把误差传导进主数据源。4.3 站台灯条与车门编号的对位偏差站台屏蔽门较多、编号较多列车停靠时司机对标位置稍有偏差就会出现车厢与站台门的对位错位。灯条指示的是“1号车厢宽松”结果乘客站在2号门口抬头看到的是3号车厢的状态数据没错但体验全错了。这个问题必须从两个层面同时解决不能只靠软件调。硬件上车载定位系统在列车进站对标停稳后会向站台控制系统发送当前准确的编组号与车厢顺序站台控制逻辑依据这个位置信息点亮对应灯条。另外车站值守人员要定期巡检灯条编号和屏蔽门编号是否一致防止线缆接错这种低级问题。4.4 小客流时段的状态展示陷阱平峰时段或末班车时段车厢载荷比较低系统逻辑上应该全部显示绿色。但偶尔会出现某一节车厢因为空调负荷骤变导致载荷传感器压力值偏高被误判为黄色“适中”。这会在没几个乘客的时段造成一种莫名的“幻觉拥挤”。修复方案就是引入“乘客光学校验”逻辑当车厢载荷值变化率过快每分钟压力波动幅度超过一定量且车门红外计数显示该时段上下车人数接近于零时系统自动将当前数据源标记为“待校验”状态并将展示端输出强制切换为同列其他车厢的中位等级。也就是说这种场景下宁可使用邻车均值也好过给乘客展示一个明显错误的单点异常值。4.5 边缘计算工控机的防尘散热管理列车上灰尘较大工控机虽然采用了无风扇设计但散热片和鳍片之间的缝隙在运营半年后容易被灰尘堵满导致CPU温度升高、处理速度下降甚至出现数据采集周期拉长到20秒以上的情况。后来在每个箱体内加装了一层工业级防尘滤棉同时要求维护作业每三个月用压缩空气清洁一次散热区域问题基本没有再复发。这个细节如果不在设计阶段就考虑进去后期就会变成让维护人员反复吐槽的痛点。轨道交通设备维护窗口本来就紧张能通过结构设计解决的问题尽量不要让人工去救火。5. 后续扩展方向与我的实际体会5.1 从“提示”到“预约”的进化方向目前这套系统解决的是“知道哪里空”但如果想进一步优化乘客体验可以叠加“拥挤度预测曲线”。基于实时载荷数据和历史客流特征用简单的时间序列算法就能预测未来15-20分钟某个方向拥挤度的变化趋势。乘客在手机端看到的就不只是当前的绿色红色还有“预计15分钟后这站会变成红色”或者“预计两站后拥挤度下降”这类前瞻性信息引导效果会远超单纯的状态展示。5.2 与运营指挥体系更深的耦合我们后续计划把车厢拥挤度数据进行多维度聚合形成“断面拥挤度热力图”让运营人员不再只看单一车次而是能看到整条线路某一断面所有经过车次的拥挤度变化情况。这个热力图一旦和行车调度系统联动起来就能做动态限速、跳停车站、区间车调整等更高阶的运营优化。5.3 个人体会工程落地比算法精准更重要的三件事做这一类轨道交通智能化改造项目我越来越清楚一件事算法模型的AUC、召回率当然要关注但真正决定项目成不成往往是三件并不“高大上”的琐事。第一是数据可信度的持续维护。传感器在实验室里测一百次都没问题但装到列车上跑三个月之后灰尘、振动、温度漂移、线缆老化都会逐个冒出来找麻烦。没有一套自动标定和自动故障标记的机制系统就会像没有维护的旧设备一样浮动得越来越厉害。第二是展示引导要以乘客的行为习惯为准而不是以数据漂亮为准。数值上显示0.1的差异在乘客眼里根本不存在区分度。把状态简化为四级、简化成颜色尽量降低乘客的理解成本效果反而比在手机端扔一堆精确数字好得多。第三是任何一项状态提示都一定要做“异常降级”不能为了系统完美运行就忽略故障照常输出错误数据。一旦出现一次“明明挤得不行灯条却显示绿色”的事故乘客对整套系统迅速建立起来的信任会在几次这样的偏差中清零。宁可让灯条在数据异常时显示灰色“请以现场为准”也不要给一个漂亮但错得离谱的误导结论。这套方案从立项到现在最让我感慨的是不同领域、不同行业的所谓智能系统到了工程现场拼到最后往往不是算法技术而是对设备状态、数据质量和用户心理的持续洞察。每次调试数据时坐在站台边上看着乘客因为灯条上的颜色提示从容走向另一扇较早预期的车门我就觉得这套系统做到了它该做的事。
