简介这份PPT方案面向智慧城市与轨道交通领域的方案设计人员、系统集成商及项目规划者围绕5G云网一体化的大数据智慧地铁应用平台系统梳理智慧车站从建设背景、目标到落地路径的完整思路可用于方案汇报、投标参考或技术选型。压缩包内为1个pptx文件约17.52MB以图文并茂的幻灯片形式呈现整体架构与实施细节。内容涵盖智慧运营、智慧服务、智慧维保三大子系统具体包括客流实时监测与预测、三线ATS监视、应急客流与行车组织、乘客5G体验区、智能服务机器人、AR远程排故及多专业综合运维等模块并给出基础设施层、应用服务层与网络资源监控的分层建设方案以及5G室分覆盖与施工计划示例。目前已有201人学习下载适合需要快速掌握智慧车站整体框架、借鉴成熟方案结构与关键技术选型的读者参考。1. 智慧车站不是大屏堆料从一份建设方案看轨道交通的落地边界很多做轨道交通信息化的团队第一次拿到「智慧城市轨道交通智慧车站系统建设方案」这类题目时第一反应是往 PPT 里塞大屏、塞 5G 基站、塞客流热力图。我在某市地铁 2 号线参与过一次智慧车站试点前期方案评审时被专家一句话问住「你这套系统早高峰断网了还能不能开闸放人」那一刻我才意识到智慧车站的核心不是炫技而是把 5G、大数据、边缘计算这些能力压到票务、安检、导向、环控这些每天都要跑的业务上还得保证降级可用。这份建设方案要解决的真实问题有三个一是车站级数据孤岛AFC、PIS、BAS、CCTV 各成体系值班站长看不到一张统一的实时态势二是大客流预警靠人工经验缺乏基于大数据的短时预测三是 5G 在站厅站台的覆盖与切片怎么和既有专网共存而不互相干扰。适合谁看适合正在写智慧车站可研报告的系统集成商、地铁公司信息化岗、以及做 5G 行业专网的工程师。下面我按「方案怎么拆、参数怎么定、坑在哪」的顺序把这份 PPT 背后的落地路径讲清楚。2. 智慧车站系统架构从 5G 专网到大数据平台的分层拆解2.1 四层架构与 5G 切片的位置一份能过评审的智慧车站方案架构图不能只画云和端。我一般按四层写感知层、网络层、平台层、应用层。感知层包括 AFC 闸机、智能安检机、客流密度摄像头、环境传感器、导向屏网络层是 5G 专网 既有有线专网的融合这里 5G 不是替代有线而是补盲和移动场景平台层是大数据集群和 AI 推理平台应用层才是值班站长看的那套智慧车站大屏和移动端。5G 在其中的角色热搜里常提「5G 关键技术」「5G 峰值速率计算公式」但车站里真正要算的不是峰值而是单站并发上行。一个站厅 20 路 4K 摄像头回传按每路 8 Mbps 算就是 160 Mbps 上行加上闸机、PIS 的状态数据单站上行预留 300 Mbps 比较稳妥。切片上一般把票务和安检划一个 uRLLC 切片视频回传划 eMBB 切片环境传感走 mMTC。参数上5G 专网的 TDD 时隙配比常用 2.5ms 双周期特殊时隙 10:2:2这个要和既有专网错开否则站台无线干扰会让闸机读卡距离缩水。提示5G 切片不是配了就有用核心网 UPF 要下沉到车站或线路中心否则回传时延压不到 20ms 以内大客流预警的实时性就没了。2.2 大数据平台的分层与集群部署策略热搜里「大数据架构包括四个层次」「大数据集群部署策略」问得很多。智慧车站的大数据平台我习惯按采集、存储、计算、服务四层落。采集层用 Flume 或 Filebeat 收 AFC 交易、摄像头结构化数据、BAS 点位存储层 HDFS 存原始数据HBase 存闸机状态和实时客流Redis 存大屏要用的秒级指标计算层 Spark 做离线客流分析Flink 做实时密度告警服务层用 API 网关把指标吐给大屏和移动端。集群部署策略上车站侧不建议放完整 Hadoop 集群太沉。常见做法是车站放边缘节点跑 Flink 和轻量推理线路中心放主集群。下面这段是边缘节点上 Flink 消费 Kafka 客流数据并做 5 分钟滑窗密度告警的最小配置可以直接抄。# flink_density_alert.py from pyflink.datastream import StreamExecutionEnvironment from pyflink.datastream.window import TumblingProcessingTimeWindows from pyflink.common.time import Time env StreamExecutionEnvironment.get_execution_environment() env.set_parallelism(2) # 边缘节点 2 核并行度别超 4 # 消费车站摄像头结构化客流数据字段station_id, zone_id, ts, person_count stream env.add_source( KafkaSource.builder() .set_bootstrap_servers(edge-kafka:9092) .set_topics(station_flow) .set_group_id(density_alert) .build() ) # 按区域开 5 分钟滚动窗口计算平均人数 result (stream .key_by(lambda x: x[zone_id]) .window(TumblingProcessingTimeWindows.of(Time.minutes(5))) .aggregate(AverageAggregator()) ) # 阈值站台区 0.8 人/㎡ 触发告警站厅区 0.5 result.filter(lambda avg: avg 0.8).print() env.execute(density_alert)逻辑说明这段代码的关键不是 Flink API而是窗口长度和阈值。5 分钟窗口是给值班站长留反应时间太短会误报太长就来不及限流。并行度设 2 是因为边缘节点通常只有 4 核还要留核给推理服务。参数上zone_id要提前和车站平面图对齐站台、站厅、换乘通道分开算混在一起算出来的密度没有意义。2.3 智慧车站应用层的三个必做功能应用层别贪多我建议第一版只做三个统一态势、大客流预警、设备健康度。统一态势把 AFC、PIS、BAS、CCTV 的状态聚到一张图大客流预警基于上面 Flink 的密度指标联动 PIS 和广播设备健康度用闸机、电梯的运行数据做简单阈值和趋势判断。这三个功能覆盖了值班站长 80% 的日常决策评审时也最容易讲清楚价值。3. 5G 与大数据在车站的落地步骤从点位勘察到联调3.1 5G 覆盖勘察与 AAU/DU/CU 安装要点热搜里「5G 设备 AAU/DU/CU 安装指导书」是很多施工队搜的。车站 5G 覆盖和室外宏站不一样站厅层高通常 4 到 6 米站台层有屏蔽门和隧道效应。我一般按三步走先做点位勘察用测试终端在站厅每 10 米打点记录 RSRP 和 SINR再定 AAU 挂点站厅用 4T4R 的 pRRU 或 AAU站台用泄漏电缆补盲最后调 DU/CU 的时隙和功率。参数上站厅 pRRU 发射功率一般设 10 到 15 dBm太高会越区干扰相邻小区站台泄漏电缆的耦合损耗要控制在 65 dB 左右。DU 和 CU 如果分离部署CU 放线路中心DU 放车站设备房前传用 25G 光模块时延要求小于 100 微秒。下面这张表是我在某站勘察时记录的典型点位参数供参考。点位区域RSRP 目标SINR 目标设备类型站厅中部付费区-85 dBm 15 dBpRRU站台端部屏蔽门外-90 dBm 12 dB泄漏电缆换乘通道通道中段-88 dBm 13 dBpRRU出入口地面-95 dBm 10 dB室外天线注意站台屏蔽门关闭时隧道内列车通过会产生多普勒频移SINR 会掉 3 到 5 dB勘察时要留余量别按空场数据定功率。3.2 大数据集群从采集到可视化的最小链路热搜里「网约车大数据综合项目——基于 Spark 的数据清洗」「校园大数据—数据可视化」这类词说明很多人卡在数据链路。智慧车站的最小链路是AFC 交易日志 → Kafka → Flink 清洗 → Hive 落仓 → Spark SQL 聚合 → API → 大屏。下面这段是 Spark SQL 按小时统计各站进站量的例子可以直接在 Hive 上跑。-- 按小时统计各站进站量用于大屏客流趋势 INSERT OVERWRITE TABLE station_hourly_flow PARTITION (dt${dt}) SELECT station_id, hour(ts) AS hour_of_day, count(*) AS enter_count, sum(CASE WHEN ticket_type single THEN 1 ELSE 0 END) AS single_count FROM afc_transaction WHERE ts ${dt} 00:00:00 AND ts ${dt} 23:59:59 AND direction enter GROUP BY station_id, hour(ts);逻辑说明这段 SQL 的坑在direction字段AFC 原始数据里进站和出站混在一起不区分就会把出站算成进站。ticket_type用来区分单程票和储值卡大屏上分开显示更有参考价值。分区按天是为了重跑历史数据时不影响其他日期。参数上${dt}用调度工具传别写死。3.3 联调阶段的三类测试联调别只测功能通不通我一般做三类压力测试、降级测试、干扰测试。压力测试用模拟器往 Kafka 灌 10 倍日常客流看 Flink 窗口会不会延迟降级测试拔掉 5G 专网看闸机能不能切回有线专网继续跑干扰测试在站台开大功率对讲机看 5G 上行速率掉多少。这三类测试做完方案才算能交。4. 避坑与排查智慧车站建设中最容易翻车的五件事4.1 5G 专网和既有专网互相干扰现象站台闸机读卡距离从 5 厘米缩到 2 厘米乘客要贴卡才能过。原因5G 专网 TDD 时隙和既有专网没对齐上行时隙撞在一起接收机饱和。解决把 5G 专网时隙配比改成和既有专网错开或者加装带通滤波器实测读卡距离恢复到 4.5 厘米以上。4.2 大数据集群磁盘写满导致 Flink 反压现象大屏客流数据延迟从 3 秒涨到 2 分钟Flink 背压指标飙红。原因HDFS 小文件太多NameNode 内存吃紧DataNode 磁盘写满。解决Flink 落 HDFS 前先做 5 分钟滚动合并小文件合并成大文件磁盘设 80% 告警提前扩容。这个坑我踩过两次血泪经验是别等写满才处理。4.3 客流密度阈值拍脑袋定现象早高峰大屏疯狂告警值班站长直接关掉告警。原因阈值按网上通用值 1 人/㎡ 设没考虑本站站台宽度和客流构成。解决用历史数据回测取过去一个月同时段 95 分位值作为初始阈值再按现场微调。站台和站厅分开设别用一个数。4.4 5G 切片配了但 UPF 没下沉现象大客流预警从摄像头到平台时延 80ms联动广播慢半拍。原因UPF 放在线路中心回传绕了一圈。解决UPF 下沉到车站或线路边缘机房时延压到 20ms 以内。这个改动要在方案初期就定后期改网络拓扑很麻烦。4.5 大屏指标口径和 AFC 对不上现象大屏显示进站 1.2 万AFC 报表 1.1 万运营方质疑数据不准。原因大屏用了 Kafka 实时流AFC 报表用了 T1 批处理两者对「进站」的定义不同实时流把重复刷卡的也算进去了。解决统一口径实时流加去重逻辑按卡号 时间窗去重或者大屏直接标注「实时估算以 AFC 报表为准」。5. 进阶技巧用历史数据回测把大客流预警准确率提上去方案交付后真正拉开差距的是预警准确率。我一般用历史数据做回测把过去三个月的 AFC 交易和摄像头密度数据按 5 分钟粒度对齐用 Spark 跑一遍预警逻辑统计误报率和漏报率。误报率高就调高阈值漏报率高就调低阈值或者引入天气、节假日特征。下面这段是回测的 Spark 代码框架。# backtest_alert.py from pyspark.sql import SparkSession from pyspark.sql.functions import col, window, avg spark SparkSession.builder.appName(alert_backtest).getOrCreate() # 读历史密度数据和实际限流记录 density spark.read.parquet(/data/density_history) limit_events spark.read.parquet(/data/limit_events) # 按 5 分钟窗口算平均密度 density_5min density.groupBy( window(col(ts), 5 minutes), col(zone_id) ).agg(avg(person_count).alias(avg_density)) # 和实际限流记录 join统计预警命中 joined density_5min.join(limit_events, [zone_id], left) hit joined.filter((col(avg_density) 0.8) (col(limit_events.ts).isNotNull())).count() total joined.filter(col(avg_density) 0.8).count() print(f命中率: {hit/total:.2%})逻辑说明回测的关键是标签limit_events是实际发生限流或广播的记录没有这个标签就没法算准确率。参数上窗口 5 分钟和线上一致阈值先固定 0.8跑完看命中率再调。我一般会把命中率做到 85% 以上才上线低于这个数值班站长不会信。最后一个习惯每次调完阈值我都会把当天的误报和漏报截图存下来下次评审时直接翻记录比讲原理管用。智慧车站这事方案写得再漂亮不如早高峰不出事。希望帮到你。本文还有配套的精品资源点击获取
智慧车站建设方案落地指南：5G专网与大数据平台实战
简介这份PPT方案面向智慧城市与轨道交通领域的方案设计人员、系统集成商及项目规划者围绕5G云网一体化的大数据智慧地铁应用平台系统梳理智慧车站从建设背景、目标到落地路径的完整思路可用于方案汇报、投标参考或技术选型。压缩包内为1个pptx文件约17.52MB以图文并茂的幻灯片形式呈现整体架构与实施细节。内容涵盖智慧运营、智慧服务、智慧维保三大子系统具体包括客流实时监测与预测、三线ATS监视、应急客流与行车组织、乘客5G体验区、智能服务机器人、AR远程排故及多专业综合运维等模块并给出基础设施层、应用服务层与网络资源监控的分层建设方案以及5G室分覆盖与施工计划示例。目前已有201人学习下载适合需要快速掌握智慧车站整体框架、借鉴成熟方案结构与关键技术选型的读者参考。1. 智慧车站不是大屏堆料从一份建设方案看轨道交通的落地边界很多做轨道交通信息化的团队第一次拿到「智慧城市轨道交通智慧车站系统建设方案」这类题目时第一反应是往 PPT 里塞大屏、塞 5G 基站、塞客流热力图。我在某市地铁 2 号线参与过一次智慧车站试点前期方案评审时被专家一句话问住「你这套系统早高峰断网了还能不能开闸放人」那一刻我才意识到智慧车站的核心不是炫技而是把 5G、大数据、边缘计算这些能力压到票务、安检、导向、环控这些每天都要跑的业务上还得保证降级可用。这份建设方案要解决的真实问题有三个一是车站级数据孤岛AFC、PIS、BAS、CCTV 各成体系值班站长看不到一张统一的实时态势二是大客流预警靠人工经验缺乏基于大数据的短时预测三是 5G 在站厅站台的覆盖与切片怎么和既有专网共存而不互相干扰。适合谁看适合正在写智慧车站可研报告的系统集成商、地铁公司信息化岗、以及做 5G 行业专网的工程师。下面我按「方案怎么拆、参数怎么定、坑在哪」的顺序把这份 PPT 背后的落地路径讲清楚。2. 智慧车站系统架构从 5G 专网到大数据平台的分层拆解2.1 四层架构与 5G 切片的位置一份能过评审的智慧车站方案架构图不能只画云和端。我一般按四层写感知层、网络层、平台层、应用层。感知层包括 AFC 闸机、智能安检机、客流密度摄像头、环境传感器、导向屏网络层是 5G 专网 既有有线专网的融合这里 5G 不是替代有线而是补盲和移动场景平台层是大数据集群和 AI 推理平台应用层才是值班站长看的那套智慧车站大屏和移动端。5G 在其中的角色热搜里常提「5G 关键技术」「5G 峰值速率计算公式」但车站里真正要算的不是峰值而是单站并发上行。一个站厅 20 路 4K 摄像头回传按每路 8 Mbps 算就是 160 Mbps 上行加上闸机、PIS 的状态数据单站上行预留 300 Mbps 比较稳妥。切片上一般把票务和安检划一个 uRLLC 切片视频回传划 eMBB 切片环境传感走 mMTC。参数上5G 专网的 TDD 时隙配比常用 2.5ms 双周期特殊时隙 10:2:2这个要和既有专网错开否则站台无线干扰会让闸机读卡距离缩水。提示5G 切片不是配了就有用核心网 UPF 要下沉到车站或线路中心否则回传时延压不到 20ms 以内大客流预警的实时性就没了。2.2 大数据平台的分层与集群部署策略热搜里「大数据架构包括四个层次」「大数据集群部署策略」问得很多。智慧车站的大数据平台我习惯按采集、存储、计算、服务四层落。采集层用 Flume 或 Filebeat 收 AFC 交易、摄像头结构化数据、BAS 点位存储层 HDFS 存原始数据HBase 存闸机状态和实时客流Redis 存大屏要用的秒级指标计算层 Spark 做离线客流分析Flink 做实时密度告警服务层用 API 网关把指标吐给大屏和移动端。集群部署策略上车站侧不建议放完整 Hadoop 集群太沉。常见做法是车站放边缘节点跑 Flink 和轻量推理线路中心放主集群。下面这段是边缘节点上 Flink 消费 Kafka 客流数据并做 5 分钟滑窗密度告警的最小配置可以直接抄。# flink_density_alert.py from pyflink.datastream import StreamExecutionEnvironment from pyflink.datastream.window import TumblingProcessingTimeWindows from pyflink.common.time import Time env StreamExecutionEnvironment.get_execution_environment() env.set_parallelism(2) # 边缘节点 2 核并行度别超 4 # 消费车站摄像头结构化客流数据字段station_id, zone_id, ts, person_count stream env.add_source( KafkaSource.builder() .set_bootstrap_servers(edge-kafka:9092) .set_topics(station_flow) .set_group_id(density_alert) .build() ) # 按区域开 5 分钟滚动窗口计算平均人数 result (stream .key_by(lambda x: x[zone_id]) .window(TumblingProcessingTimeWindows.of(Time.minutes(5))) .aggregate(AverageAggregator()) ) # 阈值站台区 0.8 人/㎡ 触发告警站厅区 0.5 result.filter(lambda avg: avg 0.8).print() env.execute(density_alert)逻辑说明这段代码的关键不是 Flink API而是窗口长度和阈值。5 分钟窗口是给值班站长留反应时间太短会误报太长就来不及限流。并行度设 2 是因为边缘节点通常只有 4 核还要留核给推理服务。参数上zone_id要提前和车站平面图对齐站台、站厅、换乘通道分开算混在一起算出来的密度没有意义。2.3 智慧车站应用层的三个必做功能应用层别贪多我建议第一版只做三个统一态势、大客流预警、设备健康度。统一态势把 AFC、PIS、BAS、CCTV 的状态聚到一张图大客流预警基于上面 Flink 的密度指标联动 PIS 和广播设备健康度用闸机、电梯的运行数据做简单阈值和趋势判断。这三个功能覆盖了值班站长 80% 的日常决策评审时也最容易讲清楚价值。3. 5G 与大数据在车站的落地步骤从点位勘察到联调3.1 5G 覆盖勘察与 AAU/DU/CU 安装要点热搜里「5G 设备 AAU/DU/CU 安装指导书」是很多施工队搜的。车站 5G 覆盖和室外宏站不一样站厅层高通常 4 到 6 米站台层有屏蔽门和隧道效应。我一般按三步走先做点位勘察用测试终端在站厅每 10 米打点记录 RSRP 和 SINR再定 AAU 挂点站厅用 4T4R 的 pRRU 或 AAU站台用泄漏电缆补盲最后调 DU/CU 的时隙和功率。参数上站厅 pRRU 发射功率一般设 10 到 15 dBm太高会越区干扰相邻小区站台泄漏电缆的耦合损耗要控制在 65 dB 左右。DU 和 CU 如果分离部署CU 放线路中心DU 放车站设备房前传用 25G 光模块时延要求小于 100 微秒。下面这张表是我在某站勘察时记录的典型点位参数供参考。点位区域RSRP 目标SINR 目标设备类型站厅中部付费区-85 dBm 15 dBpRRU站台端部屏蔽门外-90 dBm 12 dB泄漏电缆换乘通道通道中段-88 dBm 13 dBpRRU出入口地面-95 dBm 10 dB室外天线注意站台屏蔽门关闭时隧道内列车通过会产生多普勒频移SINR 会掉 3 到 5 dB勘察时要留余量别按空场数据定功率。3.2 大数据集群从采集到可视化的最小链路热搜里「网约车大数据综合项目——基于 Spark 的数据清洗」「校园大数据—数据可视化」这类词说明很多人卡在数据链路。智慧车站的最小链路是AFC 交易日志 → Kafka → Flink 清洗 → Hive 落仓 → Spark SQL 聚合 → API → 大屏。下面这段是 Spark SQL 按小时统计各站进站量的例子可以直接在 Hive 上跑。-- 按小时统计各站进站量用于大屏客流趋势 INSERT OVERWRITE TABLE station_hourly_flow PARTITION (dt${dt}) SELECT station_id, hour(ts) AS hour_of_day, count(*) AS enter_count, sum(CASE WHEN ticket_type single THEN 1 ELSE 0 END) AS single_count FROM afc_transaction WHERE ts ${dt} 00:00:00 AND ts ${dt} 23:59:59 AND direction enter GROUP BY station_id, hour(ts);逻辑说明这段 SQL 的坑在direction字段AFC 原始数据里进站和出站混在一起不区分就会把出站算成进站。ticket_type用来区分单程票和储值卡大屏上分开显示更有参考价值。分区按天是为了重跑历史数据时不影响其他日期。参数上${dt}用调度工具传别写死。3.3 联调阶段的三类测试联调别只测功能通不通我一般做三类压力测试、降级测试、干扰测试。压力测试用模拟器往 Kafka 灌 10 倍日常客流看 Flink 窗口会不会延迟降级测试拔掉 5G 专网看闸机能不能切回有线专网继续跑干扰测试在站台开大功率对讲机看 5G 上行速率掉多少。这三类测试做完方案才算能交。4. 避坑与排查智慧车站建设中最容易翻车的五件事4.1 5G 专网和既有专网互相干扰现象站台闸机读卡距离从 5 厘米缩到 2 厘米乘客要贴卡才能过。原因5G 专网 TDD 时隙和既有专网没对齐上行时隙撞在一起接收机饱和。解决把 5G 专网时隙配比改成和既有专网错开或者加装带通滤波器实测读卡距离恢复到 4.5 厘米以上。4.2 大数据集群磁盘写满导致 Flink 反压现象大屏客流数据延迟从 3 秒涨到 2 分钟Flink 背压指标飙红。原因HDFS 小文件太多NameNode 内存吃紧DataNode 磁盘写满。解决Flink 落 HDFS 前先做 5 分钟滚动合并小文件合并成大文件磁盘设 80% 告警提前扩容。这个坑我踩过两次血泪经验是别等写满才处理。4.3 客流密度阈值拍脑袋定现象早高峰大屏疯狂告警值班站长直接关掉告警。原因阈值按网上通用值 1 人/㎡ 设没考虑本站站台宽度和客流构成。解决用历史数据回测取过去一个月同时段 95 分位值作为初始阈值再按现场微调。站台和站厅分开设别用一个数。4.4 5G 切片配了但 UPF 没下沉现象大客流预警从摄像头到平台时延 80ms联动广播慢半拍。原因UPF 放在线路中心回传绕了一圈。解决UPF 下沉到车站或线路边缘机房时延压到 20ms 以内。这个改动要在方案初期就定后期改网络拓扑很麻烦。4.5 大屏指标口径和 AFC 对不上现象大屏显示进站 1.2 万AFC 报表 1.1 万运营方质疑数据不准。原因大屏用了 Kafka 实时流AFC 报表用了 T1 批处理两者对「进站」的定义不同实时流把重复刷卡的也算进去了。解决统一口径实时流加去重逻辑按卡号 时间窗去重或者大屏直接标注「实时估算以 AFC 报表为准」。5. 进阶技巧用历史数据回测把大客流预警准确率提上去方案交付后真正拉开差距的是预警准确率。我一般用历史数据做回测把过去三个月的 AFC 交易和摄像头密度数据按 5 分钟粒度对齐用 Spark 跑一遍预警逻辑统计误报率和漏报率。误报率高就调高阈值漏报率高就调低阈值或者引入天气、节假日特征。下面这段是回测的 Spark 代码框架。# backtest_alert.py from pyspark.sql import SparkSession from pyspark.sql.functions import col, window, avg spark SparkSession.builder.appName(alert_backtest).getOrCreate() # 读历史密度数据和实际限流记录 density spark.read.parquet(/data/density_history) limit_events spark.read.parquet(/data/limit_events) # 按 5 分钟窗口算平均密度 density_5min density.groupBy( window(col(ts), 5 minutes), col(zone_id) ).agg(avg(person_count).alias(avg_density)) # 和实际限流记录 join统计预警命中 joined density_5min.join(limit_events, [zone_id], left) hit joined.filter((col(avg_density) 0.8) (col(limit_events.ts).isNotNull())).count() total joined.filter(col(avg_density) 0.8).count() print(f命中率: {hit/total:.2%})逻辑说明回测的关键是标签limit_events是实际发生限流或广播的记录没有这个标签就没法算准确率。参数上窗口 5 分钟和线上一致阈值先固定 0.8跑完看命中率再调。我一般会把命中率做到 85% 以上才上线低于这个数值班站长不会信。最后一个习惯每次调完阈值我都会把当天的误报和漏报截图存下来下次评审时直接翻记录比讲原理管用。智慧车站这事方案写得再漂亮不如早高峰不出事。希望帮到你。本文还有配套的精品资源点击获取
