说句实在话AFC自动售检票系统在大部分人的认知里就是地铁闸机和自助售票机但真正在这行干过的人都知道这套系统的复杂度远比表面看到的要高。前阵子跟一位做地铁AFC系统集成的老朋友聊天他吐槽了一个真实场景早高峰时段某站闸机突然大面积死机乘客全堵在通道里站长手机被打爆运维值班员到了现场第一件事就是重启设备至于为什么会死、要不要换备件、后面还会不会再犯全靠经验猜。这种故障之后救火、客流爆了才知道的被动状态恰恰就是AI最该切入的地方。AFC这些年最大的痛点不是设备不够多而是系统产生了海量数据却不会用。每台闸机的通过记录、每台售票机的交易流水、每个模块的运行日志每天都在产生但传统AFC架构里这些数据大多是孤立的、静态的只有到了对账和审计的时候才会被翻出来。AI与AFC结合核心不是用AI取代原有售检票流程而是在感知、预测、决策三个层面给老系统装上大脑。这篇文章我结合自己参与过的轨道交通AFC智能化改造项目把真正能在现场落地的应用方案、架构设计、国产化硬件适配以及实施过程中踩过的坑一次性讲清楚。无论你是系统集成商、地铁信息化从业者、AI算法工程师还是正在做产品规划的决策者应该都能从中找到直接可复用的东西。1. 先搞清楚AFC系统的痛点在哪里AI才有用武之地1.1 AFC的五层体系一张票卡背后的完整链路AFC不是一台闸机那么简单。业内标准的分层架构是五层体系从下往上依次是车票层、终端设备层、车站计算机层SC、线路中央计算机层LCC/CC和清分结算中心层ACC/IQC。车票层包括实体票卡、二维码、人脸生物特征等支付介质终端设备层是乘客直接接触的自动售票机TVM、自动检票机AGM、半自动售票机BOM车站层负责汇聚本站所有终端的交易数据和状态信息线路层管理整条线的票务规则和运营参数最上面的清分中心则负责多条线路之间的票款清算和账务核对。每一层都有各自的性能和可靠性要求层与层之间通过专用网络连接上下行数据有严格的协议规范。这套体系在轨道交通里跑了二十多年稳定性和交易准确性是经过大规模验证的。但也正因为设计得早整个架构偏向于交易闭环而非数据开放。交易数据、设备状态数据、视频数据、语音数据各自为政连不到一起这就是AI介入的第一个障碍同时也是第一个机会。1.2 传统AFC架构的三大硬伤数据孤岛、规则静态、运维被动我在多个项目里感受最深的是这三件事。第一是数据孤岛。AFC系统里每台闸机的控制器日志、SC层的客流统计、ACC层的清分数据格式不统一且分散存储。有一次做客流分析我需要把某站早高峰的进站数据和对应时段的设备故障记录关联起来结果发现设备日志在SC层只保留7天交易数据在ACC层保留5年两边的时间戳精度还不一致光是数据对齐就花了两周。这种基础设施层面的问题直接决定了后面AI模型能用多深。第二是规则静态。传统AFC的客流预警、设备报警都是预设阈值触发的比如车站15分钟内进站量超过3000人次就报警。但问题是报警的时候客流已经形成拥堵了属于事后诸葛亮。闸机扇门的故障代码也是跑出来的那一刻才会报可故障往往不是瞬间发生的它是逐渐劣化的——读写器天线信号一天天变弱纸币识别模块的卡钞率一点点升高这些渐进式异常传统系统根本不会提前告诉你。第三是运维被动。设备坏了靠故障代码触发维修工单修不修得好看维护人员的个人经验。备件库存是按历史消耗量粗放采购的经常出现读写器坏得最多的站备件不足坏得少的站备件积压的情况。这不是管理不努力而是因为缺乏对设备健康度的量化评估手段。1.3 AI的正确切入方式感知增强、决策辅助、预测前置把痛点拆开之后AI的定位就清楚了不是去替代AFC的核心交易逻辑而是做三件事。感知增强利用摄像头、拾音器、传感器数据通过计算机视觉和语音识别模型把原来看得到但没人看的画面变成结构化业务事件比如尾随、逆行、翻越闸机、设备异响。决策辅助用机器学习模型替代固定规则做动态客流预测、设备健康度评估、票务策略优化。预测前置把设备维护从故障后维修变成故障前预警给运维留出充足的响应时间。这三件事说起来简单真正落地时每一件都要处理数据、算法、工程三个层面的问题。下面我按场景逐个拆解。2. 五大关键应用场景拆解从业务需求到可落地的技术方案2.1 无感通行人脸识别过闸关键是时延和误识率人脸识别过闸是AFCAI最直观的应用乘客预先在APP或线下网点完成人脸注册绑定票务账户过闸时摄像头抓拍人脸系统完成1:N检索比对识别通过后自动开闸。这个场景最核心的技术指标有三个全部是硬指标。第一是端到端时延。从摄像头抓拍帧到闸机开闸指令发出业内普遍要求控制在500毫秒以内否则早高峰通行速度会明显下降。我做过实测在边缘设备上用MobileFaceNetArcFace做特征提取加上底库检索单次识别大约250到300毫秒加上图像采集和闸门驱动的时间是能满足要求的。第二是误识率FAR这个指标要求极高目标通常是百万分之一以下。闸机场景不像手机解锁手机解锁错了自己可以纠正闸机如果A刷脸开了闸B跟着进来了那就是一起票务纠纷。第三是底库规模一个换乘大站的注册用户可能在几十万量级在嵌入式设备上做几十万规模的1:N特征检索需要把特征量化成紧凑向量并用高效的近似最近邻检索算法。工程上还有几个容易被忽略的细节。多目标同时过闸时多个人脸会同时在画面里出现必须先做行人检测和跟踪给每个人分配轨迹ID再按轨迹取最清晰的人脸帧做识别。戴口罩场景要和戴口罩检测配合识别失败了要能快速切换二维码或刷卡兜底。活体检测必须做否则一张打印照片就能骗过系统现场一般用IR红外摄像头加RGB双目方案。另外人脸数据涉及个人生物识别信息采集和存储环节需要明确的用户授权加密存储和访问审计这些基础工作一个都不能省。2.2 客流感知与预测从闸机堵了才知道到提前一小时预判客流预测是另外一个大场景而且它不依赖新增硬件只要把AFC系统已有的进出站交易数据用好就能产生明显价值。具体来说就是基于历史OD起讫点数据、天气、节假日、大型活动日历、周边施工封路等外部信息训练时间序列模型预测未来15分钟、30分钟、1小时甚至全天的客流。模型选型上我建议分两步走。第一步先做快速基线用Prophet或者XGBoost等成熟算法把历史客流数据的周期性、节假日效应拟合出来。基线模型的好处是训练快、可解释性强能让运营团队先建立起对AI的信任。第二步再上LSTM或者Informer这类深度序列模型把天气、温度、降水、活动等外生变量一起加进去提升预测精度。评价指标主要看MAPE也就是平均绝对百分比误差平峰期一般能做到8%以内但大型活动散场这种极端场景误差会明显偏大需要在模型之外增加人工干预的接口比如提前录入活动散场时间做场景化修正。预测结果怎么用是落地关键。车站端可以提前30到60分钟接到大客流预警及时增开安检通道、调整闸机进出方向调度端可以据此调整列车运行图商业开发部门还能把预测数据和站内商铺的销售数据结合优化资源投放。我见过一个做的比较好的案例运营单位把客流预测接入到车站值班员的工作台每天早晚高峰前推送当日分时客流曲线和去年同期对比值班员对站内人力排班的安排更有底了。2.3 智能防逃票视频分析让尾随和翻越无所遁形逃票是AFC运营里长期存在的痛点。传统闸机依靠红外对射检测通道内是否有物体但红外检测只能判断通道有东西判断不了是不是跟着持票人一起进来的。加人工监视成本太高也盯不过来。AI视频分析给了这个场景一个行之有效的答案。技术方案是在闸机通道上方安装摄像头用目标检测模型YOLOv8n这类轻量模型就够实时检测通道内行人再用ByteTrack或DeepSort这类多目标跟踪算法给每个人分配ID和轨迹。核心判断逻辑是闸门开启放行后如果跟踪到的行人数量多于1个就判定为尾随事件。跳闸、钻闸、逆行等行为可以通过划定区域和姿态估计来识别比如检测到人形目标出现在闸机门体上方区域且停留时间超过阈值告警就触发了。这个场景落地时要特别控制误报率。地铁每天几百万客流哪怕误报率只有千分之一一天也会有几千条无效告警运营人员很快就麻木了。我的做法是设计两级响应机制单次异常只做提示级标记同一通道同一类异常在短时间内连续出现3次以上才升级为确认级告警推送给车站综控室。告警附带的截图和前后10秒视频片段自动保存供后续稽核使用。配套的还有隐私合规问题通道视频只做实时分析和短时留存不作为长期监控数据这个边界要在方案设计时就定清楚。2.4 预测性维护让设备在罢工前说话AFC设备里故障率最高的几个部件我列个清单纸币识别模块的卡钞和机械磨损、票卡读写器的天线老化、闸机扇门电机的开合寿命、BOM打印机的卡纸和断针。这些东西的共同特点是故障不是瞬发的而是有一个劣化过程只是传统系统只在最终故障时报警中间的过程数据全被丢掉了。预测性维护的做法是把设备运行日志变成时序特征再用模型学习正常和异常的模式差异。具体特征可以设计成读写器最近100次操作的成功率、扇门电机每一次开关动作的耗时及波动、纸币模块的卡钞率、设备CPU温度曲线等等。算法上无监督异常检测用Isolation Forest或Autoencoder能在缺少故障标签的冷启动阶段先跑起来有标签之后用梯度提升树或生存分析模型直接预测剩余寿命。我举一个读写器的例子。某线路的设备数据显示读写器写卡失败率从0.2%缓慢爬升到1.5%同时操作响应时间增加了约15毫秒这些早期信号出现之后平均再过10到14天设备就会彻底失效。抓住这个窗口期提前更换备件就能把设备故障对运营的影响降到接近零。预测性维护的产出要对接工单系统不是算法报一个健康度72分就完了而是要自动生成建议工单写上建议3日内更换3号口进站闸机1号读写器维修人员照单执行就行。2.5 智能票务服务与运营决策把乘客体验和商业策略一起做除了上述几个偏硬核的场景AI在AFC里还有不少轻应用。语音购票就是很实用的一类在TVM上集成语音识别和对话生成乘客说我要去人民广场站一张票设备自动完成线路查询、票价计算和支付引导这对老年人和外地游客特别友好。车站问询机器人也是类似原理结合知识库回答首末班车时间、换乘路径、票价规则这些高频问题。票务策略优化这块目前做得比较谨慎公共交通票价的调整涉及面广AI更多是用在个性化推荐上。比如根据乘客的历史通勤规律推荐更划算的周卡、月卡或计次票根据大客流预测结果在商业活动散场时段定向推送公交接驳优惠券。这些应用虽然单个体量不大但对提升非票务收入和乘客满意度都有实际帮助而且上线风险极低。3. 融合架构怎么搭AFCAI的系统设计与集成3.1 端-边-云三层架构每一层算力都物尽其用AI要落地AFC这种高可靠生产系统架构上最忌讳的就是什么都往中心化平台塞网络抖动一下全线功能就瘫了。我设计过一套端-边-云三层架构每一层承担不同的任务互相之间还留有降级通道。端侧是闸机、售票机内置的AI计算模块负责时延敏感且与实时控制强相关的推理任务典型就是人脸识别和活体检测。这一层的算力不需要很夸张一块支持INT8量化的嵌入式芯片就够关键是低功耗、低时延、高稳定性。边侧是车站级的边缘服务器部署视频分析、客流统计、设备健康监测这类覆盖整个车站的AI应用。它接收该站所有通道摄像头的视频流和终端设备的日志流做处理后再把结构化结果上传。云侧是线网级的AI平台承担模型训练、全量底库管理、数据汇聚分析和业务闭环。云端可以放在线路中心或清分中心的私有云环境里与AFC生产网络逻辑隔离。三层之间有一个很重要的原则边缘和端侧的AI应用必须能在断网情况下独立运行。闸机的人脸识别底库可以定期从云端同步到本地进站高峰期哪怕到云端的链路完全断开端侧照样能完成识别和开闸。这一点对于轨道交通的高可用性要求来说是没得商量的硬指标。3.2 数据管道建设从设备日志到AI特征的完整路径AI的上限取决于数据质量这句话在AFC场景里尤其成立。建数据管道的第一步是统一日志格式。AFC设备来自多家厂商日志格式五花八门有的是文本文件有的是数据库记录时间戳精度还不一致。我们当时推动所有终端厂商按统一JSON schema输出结构化日志字段至少包括设备ID、设备类型、事件类型、发生时间、持续时间、关键参数。这个工作在商务和技术上都有阻力但必须做否则后面数据处理全是坑。数据接入层用消息队列削峰填谷。闸机的交易日志在早晚高峰会产生脉冲式的流量峰值直接写数据库很容易被打满。建议的做法是终端日志先汇入Kafka由实时流处理任务消费并做初步清洗再分别落入时序数据库设备状态类和列式数仓交易分析类。特征工程在离线数仓里完成比如按设备ID和小时粒度聚合出读写器失败率闸门动作时长设备温度波动这些特征。模型服务层提供标准API供上层应用调用在线推理和离线批量推理分开部署。3.3 模型选型与推理性能AFC场景的硬指标约束不同的AFC业务场景模型选型和性能要求差异很大我整理了一个可以直接参考的表格应用场景算法/模型推理硬件要求时延要求精度关键指标人脸特征提取MobileFaceNetArcFace边缘NPU/GPU单次识别300ms误识率1e-6行人检测YOLOv8n/s边缘NPU50ms/帧漏检率1%多目标跟踪ByteTrack/DeepSort边缘CPU实时ID切换率低客流预测Informer/LSTM/XGBoost云端CPU/GPU分钟级MAPE10%设备异常检测Autoencoder/IForest云端CPU秒级召回率90%语音购票ASRNLU流水线终端/边缘CPU2s完成交互意图识别准确率95%这里有个容易被忽略的点嵌入式那个端侧并不是跑得动大模型才有用。我反复跟算法团队强调AFC现场是资源受限环境模型不是越大越准而是要在精度和时延之间找平衡。通过知识蒸馏把大模型的能力压缩到小模型再用INT8量化进一步把模型体积和推理时延降下来量化后精度损失通常控制在1%以内这在AFC应用里是完全可接受的。3.4 集成策略AI不能成为核心交易链路的故障点做轨道交通系统集成最重要的原则是核心链路不能被旁路系统拖垮。AI系统在AFC整体架构里定位是旁路增强它只能给原有系统提供辅助建议和增强信息不能替代AFC核心控制器做最终决策。以人脸识别过闸为例正确的集成方式是AI识别模块把比对结果封装成建议开闸信号通过IO或以太网发给AFC闸机控制器闸机控制器再结合自身的红外检测、闸门锁闭状态、票务规则做最终开闸决策。如果AI模块故障或超时闸机自动回退到二维码/刷卡通行模式乘客侧基本无感知。网络上也建议做隔离AI子系统和AFC核心网络之间走白名单访问只开放必要的API端口。我在项目里见过因为AI服务异常导致闸机暂停服务的案例根因就是集成时图省事把AI直连进了闸机核心控制回路这种设计在轨道交通行业是不可以被接受的。4. 国产化工控平台的AI落地实战以龙芯2K3000为代表4.1 轨道交通AFC为什么越来越关注国产化算力平台做AFC系统集成的人这几年应该都有明显的感知新建线路和既有线改造项目里国产化算力平台的比重在持续提升。这里面有供应链稳定性的现实考虑。轨道交通设备的设计寿命是10到15年一条线路几十个站、几千台终端设备如果核心芯片的供货周期不稳定对后续维护和扩容的影响是毁灭性的。国产平台在这一点上有明显的优势长期供货保障更可靠。从技术层面看国产芯片这几年的能力提升也撑得起来了。过去大家担心的性能弱、工具链不完善、生态封闭这些老问题已经有了明显改善。龙芯的LoongArch指令集在工控领域逐渐打开局面OpenVINO、ONNX Runtime这类主流推理框架也完成了适配AI落地的技术障碍在降低。加上AFC设备对算力的需求本身不算极端——主要是嵌入式级的AI推理而不是高性能训练——这些都让国产平台在AFC场景里的可行性大幅提高。4.2 龙芯2K3000平台的性能画像与适配要点具体到龙芯2K3000这颗SoC它在AFC场景里是一款定位比较精准的产品。公开资料显示它面向工控和嵌入式应用基于LoongArch指令集架构多核心设计主频在GHz级别集成了显示控制器支持多屏输出这对AFC终端设备是刚需——一台售票机往往需要同时驱动触摸操作屏和面向乘客的展示屏。接口方面千兆以太网、多路USB、串口、CAN等工控外设接口是比较齐全的对接闸机控制器、纸币识别器、票卡读写器、打印机这些AFC标准外设没有明显短板。比较关键的一点是这颗SoC本身没有高算力的NPU所以在端侧做AI推理要靠两种方案一是纯CPU推理加SIMD指令优化适合MobileFaceNet、YOLOv8n这类轻量模型二是通过PCIe或USB外接AI加速卡适合对算力要求更高的任务。车站级边缘服务器可以选配性能更高的龙芯或同生态平台把视频分析和多路检测这类重任务放在边侧处理。4.3 在龙芯平台部署AI模型的实操过程与调优经验我在一个闸机AI模块迁移项目里把原先生成在x86平台上的PyTorch人脸识别模型迁移到龙芯平台的CPU上跑整个流程可以概括为四个步骤。第一步模型导出。在x86训练环境把PyTorch模型导出为ONNX格式固定输入尺寸和batch size这一步剔除掉训练才需要的动态shape和算子让推理图更干净。第二步模型量化。用ONNX Runtime的INT8量化工具拿一批实际场景数据做校准把FP32模型转成INT8模型。我实测下来INT8量化之后人脸特征提取模型体积缩小约四分之三推理速度提升约2到3倍识别精度基本持平。第三步交叉编译和部署准备。在x86开发机上用龙芯的交叉编译工具链把ONNX Runtime以及相关的图像预处理代码编译成LoongArch可执行文件再与模型文件一起拷贝到目标设备。第四步推理测试和调优。重点观察首帧时延和连续运行的稳定性。实际调优中还有几个值得分享的经验。数据预处理要和推理解耦图像缩放、归一化这些计算放到单独的线程里避免阻塞推理主流程。内存管理上AFC终端的内存有限推理时的输入输出缓冲区用内存池复用避免频繁malloc/free造成碎片。多线程并行时要留意锁的开销如果核心业务路径上锁竞争太高考虑用无锁队列或者读写锁优化。4.4 国产化平台迁移的坑点清单每一条都是真金白银换来的国产化迁移最大的坑不在芯片本身而在生态配套。我列一份踩坑清单后面做同类项目的人能少走不少弯路。外设驱动是第一个坎。AFC终端里的纸币识别器、票卡读写器、闸机电机驱动板很多是传统工控外设原厂驱动只提供x86版本没有LoArch版本。这个必须在项目启动早期就跟整机厂商和核心外设厂商确认适配计划不能等到系统联调了才发现驱动没有。嵌入式系统迁移也很关键原有应用如果是基于Windows的迁移到Linux加LoongArch后界面框架、串口通信、数据库驱动都要重新验证建议产品在架构设计阶段就采用Qt这类跨平台框架降低迁移成本。实时性同样要重点验证。闸机电机控制在某些环节对IO响应时延有要求如果在标准Linux内核上时序抖动太大就要考虑采用实时性增强方案或者把实时控制任务放在专门的控制板上不跟AI推理抢CPU。最后迁移后测试矩阵不能简化温度循环、温湿度、EMC电磁兼容、7乘24小时长稳测试都要按轨道交通标准重新过一遍不能因为芯片是新的就跳过可靠性验证。5. 试点到推广实施路径与真实踩坑记录5.1 试点车站怎么选三个标准缺一不可AI在AFC场景里落地最忌讳一上来就全线铺开。合理的路径是先选一个或几个试点站跑通验证技术可行性、运营配合度和真实效果再逐步扩大。选试点站我一般用三个标准。第一是业务价值要高选客流大、逃票现象相对突出、设备故障频率高的车站这种站AI效果容易体现也方便算清楚ROI。第二是网络条件要好AI边缘节点的运行依赖站级网络质量选一个网络基础好的站可以避免业务没验证出来先被网络问题捆住手脚。第三是运营团队要愿意配合AI系统上线初期一定会有误报、漏报和各种需要人工确认的情况如果车站团队抵触情绪大试点很容易被负面反馈淹没。5.2 数据冷启动与样本不均衡做AI落地最先碰到的两座山冷启动阶段最大的问题就是没标签。逃票检测场景里正常通行样本和逃票样本的比例可能差几千倍直接训练一个二分类模型模型会学成永远输出正常因为这样准确率也高达99.9%。解决思路是采用无监督或半监督方案作为冷启动先用目标检测加规则判定去发现闸机开启后通道内出现了多个行人这类强规则事件积累一批疑似逃票数据再由运营人员确认打标形成初始训练集。后续再通过重采样、合成样本等方式缓解类别不平衡。设备故障数据也存在类似问题。很多线路的历史运维数据并不完善故障标签缺失严重。我的做法是把规则引擎和无监督异常检测结合规则引擎先筛出明确故障故障码报警无监督模型负责发现未知的异常模式人工复核后反哺标签体系。这种方法跨几个项目验证下来性价比很高。5.3 模型上线不能一刀切灰度发布、A/B测试和快速回退AI模型上线和传统软件发布有一个很大区别模型的精度会漂移场景变化会导致效果下降。所以不能搞一次性全量切换必须有一套持续上线的机制。我们当时的做法是给每个模型建立版本档案记录训练数据集范围、训练日期、评测指标和变更说明。上线采用灰度策略先在一个车站或一条通道作为实验组运行和相邻通道的对照组做效果对比用通行效率、识别准确率、误报率、乘客投诉率这些指标来评估。最关键的是要预设回退预案。特别是和人脸过闸相关的模型在灰度期间如果出现误识率升高要能一键回退到上一版本整个过程乘客无感知。AFC系统是生产系统任何AI能力都必须是可插拔的这个问题上不能有任何侥幸心理。5.4 运维团队的转型以后不只是修闸机还要懂模型AI能力上线之后运维模式的变化可能比很多团队预想的更大。传统的AFC运维工程师主要修设备、换备件现在还要能看懂模型监控看板上的指标。我给团队的建议是建三块看板模型效果看板实时展示各站各场景的推理准确率、误报率、服务可用性设备健康看板直接展示预测性维护模型输出的设备健康分和剩余寿命建议运营效果看板把AI各项能力带来的客诉变化、逃票率变化、故障停机时长变化汇总到一张表上。另外建议建立每周复盘机制把AI告警的触发情况和人工确认结果做闭环比对。很多AI告警在第一次出现时会显得不正常但经过一段时间的运营反馈和模型迭代误报率会逐步降到可接受的范围。这个过程需要运营、算法、运维三方组成的小团队持续推进不能指望算法工程师远程丢一个模型就完事了。最后再分享一个我个人的体会AFCAI这种类型项目边界感比技术能力更重要。AI在轨道交通这类高可靠性行业里的定位永远是辅助决策而不是替代决策。人脸识别给你免密通行但闸机的开闸动作最终还是由AFC控制器执行AI给出设备维护建议但更换部件的指令还是走进工单流程。把这个边界想清楚项目的推进阻力会小一半。另外一个容易被低估的点是数据质量决定AI的上限。宁可花一半的精力做日志标准化和数据治理也不要急着把模型训练起来。轨道行业项目周期长、场景复杂把地基夯得足够实上面每一层才站得稳。 
长河君 · 2026/10/3 13:23:04 · 阅读 1.2k AFC智能化落地：从数据孤岛到预测性维护的AI改造实践
说句实在话AFC自动售检票系统在大部分人的认知里就是地铁闸机和自助售票机但真正在这行干过的人都知道这套系统的复杂度远比表面看到的要高。前阵子跟一位做地铁AFC系统集成的老朋友聊天他吐槽了一个真实场景早高峰时段某站闸机突然大面积死机乘客全堵在通道里站长手机被打爆运维值班员到了现场第一件事就是重启设备至于为什么会死、要不要换备件、后面还会不会再犯全靠经验猜。这种故障之后救火、客流爆了才知道的被动状态恰恰就是AI最该切入的地方。AFC这些年最大的痛点不是设备不够多而是系统产生了海量数据却不会用。每台闸机的通过记录、每台售票机的交易流水、每个模块的运行日志每天都在产生但传统AFC架构里这些数据大多是孤立的、静态的只有到了对账和审计的时候才会被翻出来。AI与AFC结合核心不是用AI取代原有售检票流程而是在感知、预测、决策三个层面给老系统装上大脑。这篇文章我结合自己参与过的轨道交通AFC智能化改造项目把真正能在现场落地的应用方案、架构设计、国产化硬件适配以及实施过程中踩过的坑一次性讲清楚。无论你是系统集成商、地铁信息化从业者、AI算法工程师还是正在做产品规划的决策者应该都能从中找到直接可复用的东西。1. 先搞清楚AFC系统的痛点在哪里AI才有用武之地1.1 AFC的五层体系一张票卡背后的完整链路AFC不是一台闸机那么简单。业内标准的分层架构是五层体系从下往上依次是车票层、终端设备层、车站计算机层SC、线路中央计算机层LCC/CC和清分结算中心层ACC/IQC。车票层包括实体票卡、二维码、人脸生物特征等支付介质终端设备层是乘客直接接触的自动售票机TVM、自动检票机AGM、半自动售票机BOM车站层负责汇聚本站所有终端的交易数据和状态信息线路层管理整条线的票务规则和运营参数最上面的清分中心则负责多条线路之间的票款清算和账务核对。每一层都有各自的性能和可靠性要求层与层之间通过专用网络连接上下行数据有严格的协议规范。这套体系在轨道交通里跑了二十多年稳定性和交易准确性是经过大规模验证的。但也正因为设计得早整个架构偏向于交易闭环而非数据开放。交易数据、设备状态数据、视频数据、语音数据各自为政连不到一起这就是AI介入的第一个障碍同时也是第一个机会。1.2 传统AFC架构的三大硬伤数据孤岛、规则静态、运维被动我在多个项目里感受最深的是这三件事。第一是数据孤岛。AFC系统里每台闸机的控制器日志、SC层的客流统计、ACC层的清分数据格式不统一且分散存储。有一次做客流分析我需要把某站早高峰的进站数据和对应时段的设备故障记录关联起来结果发现设备日志在SC层只保留7天交易数据在ACC层保留5年两边的时间戳精度还不一致光是数据对齐就花了两周。这种基础设施层面的问题直接决定了后面AI模型能用多深。第二是规则静态。传统AFC的客流预警、设备报警都是预设阈值触发的比如车站15分钟内进站量超过3000人次就报警。但问题是报警的时候客流已经形成拥堵了属于事后诸葛亮。闸机扇门的故障代码也是跑出来的那一刻才会报可故障往往不是瞬间发生的它是逐渐劣化的——读写器天线信号一天天变弱纸币识别模块的卡钞率一点点升高这些渐进式异常传统系统根本不会提前告诉你。第三是运维被动。设备坏了靠故障代码触发维修工单修不修得好看维护人员的个人经验。备件库存是按历史消耗量粗放采购的经常出现读写器坏得最多的站备件不足坏得少的站备件积压的情况。这不是管理不努力而是因为缺乏对设备健康度的量化评估手段。1.3 AI的正确切入方式感知增强、决策辅助、预测前置把痛点拆开之后AI的定位就清楚了不是去替代AFC的核心交易逻辑而是做三件事。感知增强利用摄像头、拾音器、传感器数据通过计算机视觉和语音识别模型把原来看得到但没人看的画面变成结构化业务事件比如尾随、逆行、翻越闸机、设备异响。决策辅助用机器学习模型替代固定规则做动态客流预测、设备健康度评估、票务策略优化。预测前置把设备维护从故障后维修变成故障前预警给运维留出充足的响应时间。这三件事说起来简单真正落地时每一件都要处理数据、算法、工程三个层面的问题。下面我按场景逐个拆解。2. 五大关键应用场景拆解从业务需求到可落地的技术方案2.1 无感通行人脸识别过闸关键是时延和误识率人脸识别过闸是AFCAI最直观的应用乘客预先在APP或线下网点完成人脸注册绑定票务账户过闸时摄像头抓拍人脸系统完成1:N检索比对识别通过后自动开闸。这个场景最核心的技术指标有三个全部是硬指标。第一是端到端时延。从摄像头抓拍帧到闸机开闸指令发出业内普遍要求控制在500毫秒以内否则早高峰通行速度会明显下降。我做过实测在边缘设备上用MobileFaceNetArcFace做特征提取加上底库检索单次识别大约250到300毫秒加上图像采集和闸门驱动的时间是能满足要求的。第二是误识率FAR这个指标要求极高目标通常是百万分之一以下。闸机场景不像手机解锁手机解锁错了自己可以纠正闸机如果A刷脸开了闸B跟着进来了那就是一起票务纠纷。第三是底库规模一个换乘大站的注册用户可能在几十万量级在嵌入式设备上做几十万规模的1:N特征检索需要把特征量化成紧凑向量并用高效的近似最近邻检索算法。工程上还有几个容易被忽略的细节。多目标同时过闸时多个人脸会同时在画面里出现必须先做行人检测和跟踪给每个人分配轨迹ID再按轨迹取最清晰的人脸帧做识别。戴口罩场景要和戴口罩检测配合识别失败了要能快速切换二维码或刷卡兜底。活体检测必须做否则一张打印照片就能骗过系统现场一般用IR红外摄像头加RGB双目方案。另外人脸数据涉及个人生物识别信息采集和存储环节需要明确的用户授权加密存储和访问审计这些基础工作一个都不能省。2.2 客流感知与预测从闸机堵了才知道到提前一小时预判客流预测是另外一个大场景而且它不依赖新增硬件只要把AFC系统已有的进出站交易数据用好就能产生明显价值。具体来说就是基于历史OD起讫点数据、天气、节假日、大型活动日历、周边施工封路等外部信息训练时间序列模型预测未来15分钟、30分钟、1小时甚至全天的客流。模型选型上我建议分两步走。第一步先做快速基线用Prophet或者XGBoost等成熟算法把历史客流数据的周期性、节假日效应拟合出来。基线模型的好处是训练快、可解释性强能让运营团队先建立起对AI的信任。第二步再上LSTM或者Informer这类深度序列模型把天气、温度、降水、活动等外生变量一起加进去提升预测精度。评价指标主要看MAPE也就是平均绝对百分比误差平峰期一般能做到8%以内但大型活动散场这种极端场景误差会明显偏大需要在模型之外增加人工干预的接口比如提前录入活动散场时间做场景化修正。预测结果怎么用是落地关键。车站端可以提前30到60分钟接到大客流预警及时增开安检通道、调整闸机进出方向调度端可以据此调整列车运行图商业开发部门还能把预测数据和站内商铺的销售数据结合优化资源投放。我见过一个做的比较好的案例运营单位把客流预测接入到车站值班员的工作台每天早晚高峰前推送当日分时客流曲线和去年同期对比值班员对站内人力排班的安排更有底了。2.3 智能防逃票视频分析让尾随和翻越无所遁形逃票是AFC运营里长期存在的痛点。传统闸机依靠红外对射检测通道内是否有物体但红外检测只能判断通道有东西判断不了是不是跟着持票人一起进来的。加人工监视成本太高也盯不过来。AI视频分析给了这个场景一个行之有效的答案。技术方案是在闸机通道上方安装摄像头用目标检测模型YOLOv8n这类轻量模型就够实时检测通道内行人再用ByteTrack或DeepSort这类多目标跟踪算法给每个人分配ID和轨迹。核心判断逻辑是闸门开启放行后如果跟踪到的行人数量多于1个就判定为尾随事件。跳闸、钻闸、逆行等行为可以通过划定区域和姿态估计来识别比如检测到人形目标出现在闸机门体上方区域且停留时间超过阈值告警就触发了。这个场景落地时要特别控制误报率。地铁每天几百万客流哪怕误报率只有千分之一一天也会有几千条无效告警运营人员很快就麻木了。我的做法是设计两级响应机制单次异常只做提示级标记同一通道同一类异常在短时间内连续出现3次以上才升级为确认级告警推送给车站综控室。告警附带的截图和前后10秒视频片段自动保存供后续稽核使用。配套的还有隐私合规问题通道视频只做实时分析和短时留存不作为长期监控数据这个边界要在方案设计时就定清楚。2.4 预测性维护让设备在罢工前说话AFC设备里故障率最高的几个部件我列个清单纸币识别模块的卡钞和机械磨损、票卡读写器的天线老化、闸机扇门电机的开合寿命、BOM打印机的卡纸和断针。这些东西的共同特点是故障不是瞬发的而是有一个劣化过程只是传统系统只在最终故障时报警中间的过程数据全被丢掉了。预测性维护的做法是把设备运行日志变成时序特征再用模型学习正常和异常的模式差异。具体特征可以设计成读写器最近100次操作的成功率、扇门电机每一次开关动作的耗时及波动、纸币模块的卡钞率、设备CPU温度曲线等等。算法上无监督异常检测用Isolation Forest或Autoencoder能在缺少故障标签的冷启动阶段先跑起来有标签之后用梯度提升树或生存分析模型直接预测剩余寿命。我举一个读写器的例子。某线路的设备数据显示读写器写卡失败率从0.2%缓慢爬升到1.5%同时操作响应时间增加了约15毫秒这些早期信号出现之后平均再过10到14天设备就会彻底失效。抓住这个窗口期提前更换备件就能把设备故障对运营的影响降到接近零。预测性维护的产出要对接工单系统不是算法报一个健康度72分就完了而是要自动生成建议工单写上建议3日内更换3号口进站闸机1号读写器维修人员照单执行就行。2.5 智能票务服务与运营决策把乘客体验和商业策略一起做除了上述几个偏硬核的场景AI在AFC里还有不少轻应用。语音购票就是很实用的一类在TVM上集成语音识别和对话生成乘客说我要去人民广场站一张票设备自动完成线路查询、票价计算和支付引导这对老年人和外地游客特别友好。车站问询机器人也是类似原理结合知识库回答首末班车时间、换乘路径、票价规则这些高频问题。票务策略优化这块目前做得比较谨慎公共交通票价的调整涉及面广AI更多是用在个性化推荐上。比如根据乘客的历史通勤规律推荐更划算的周卡、月卡或计次票根据大客流预测结果在商业活动散场时段定向推送公交接驳优惠券。这些应用虽然单个体量不大但对提升非票务收入和乘客满意度都有实际帮助而且上线风险极低。3. 融合架构怎么搭AFCAI的系统设计与集成3.1 端-边-云三层架构每一层算力都物尽其用AI要落地AFC这种高可靠生产系统架构上最忌讳的就是什么都往中心化平台塞网络抖动一下全线功能就瘫了。我设计过一套端-边-云三层架构每一层承担不同的任务互相之间还留有降级通道。端侧是闸机、售票机内置的AI计算模块负责时延敏感且与实时控制强相关的推理任务典型就是人脸识别和活体检测。这一层的算力不需要很夸张一块支持INT8量化的嵌入式芯片就够关键是低功耗、低时延、高稳定性。边侧是车站级的边缘服务器部署视频分析、客流统计、设备健康监测这类覆盖整个车站的AI应用。它接收该站所有通道摄像头的视频流和终端设备的日志流做处理后再把结构化结果上传。云侧是线网级的AI平台承担模型训练、全量底库管理、数据汇聚分析和业务闭环。云端可以放在线路中心或清分中心的私有云环境里与AFC生产网络逻辑隔离。三层之间有一个很重要的原则边缘和端侧的AI应用必须能在断网情况下独立运行。闸机的人脸识别底库可以定期从云端同步到本地进站高峰期哪怕到云端的链路完全断开端侧照样能完成识别和开闸。这一点对于轨道交通的高可用性要求来说是没得商量的硬指标。3.2 数据管道建设从设备日志到AI特征的完整路径AI的上限取决于数据质量这句话在AFC场景里尤其成立。建数据管道的第一步是统一日志格式。AFC设备来自多家厂商日志格式五花八门有的是文本文件有的是数据库记录时间戳精度还不一致。我们当时推动所有终端厂商按统一JSON schema输出结构化日志字段至少包括设备ID、设备类型、事件类型、发生时间、持续时间、关键参数。这个工作在商务和技术上都有阻力但必须做否则后面数据处理全是坑。数据接入层用消息队列削峰填谷。闸机的交易日志在早晚高峰会产生脉冲式的流量峰值直接写数据库很容易被打满。建议的做法是终端日志先汇入Kafka由实时流处理任务消费并做初步清洗再分别落入时序数据库设备状态类和列式数仓交易分析类。特征工程在离线数仓里完成比如按设备ID和小时粒度聚合出读写器失败率闸门动作时长设备温度波动这些特征。模型服务层提供标准API供上层应用调用在线推理和离线批量推理分开部署。3.3 模型选型与推理性能AFC场景的硬指标约束不同的AFC业务场景模型选型和性能要求差异很大我整理了一个可以直接参考的表格应用场景算法/模型推理硬件要求时延要求精度关键指标人脸特征提取MobileFaceNetArcFace边缘NPU/GPU单次识别300ms误识率1e-6行人检测YOLOv8n/s边缘NPU50ms/帧漏检率1%多目标跟踪ByteTrack/DeepSort边缘CPU实时ID切换率低客流预测Informer/LSTM/XGBoost云端CPU/GPU分钟级MAPE10%设备异常检测Autoencoder/IForest云端CPU秒级召回率90%语音购票ASRNLU流水线终端/边缘CPU2s完成交互意图识别准确率95%这里有个容易被忽略的点嵌入式那个端侧并不是跑得动大模型才有用。我反复跟算法团队强调AFC现场是资源受限环境模型不是越大越准而是要在精度和时延之间找平衡。通过知识蒸馏把大模型的能力压缩到小模型再用INT8量化进一步把模型体积和推理时延降下来量化后精度损失通常控制在1%以内这在AFC应用里是完全可接受的。3.4 集成策略AI不能成为核心交易链路的故障点做轨道交通系统集成最重要的原则是核心链路不能被旁路系统拖垮。AI系统在AFC整体架构里定位是旁路增强它只能给原有系统提供辅助建议和增强信息不能替代AFC核心控制器做最终决策。以人脸识别过闸为例正确的集成方式是AI识别模块把比对结果封装成建议开闸信号通过IO或以太网发给AFC闸机控制器闸机控制器再结合自身的红外检测、闸门锁闭状态、票务规则做最终开闸决策。如果AI模块故障或超时闸机自动回退到二维码/刷卡通行模式乘客侧基本无感知。网络上也建议做隔离AI子系统和AFC核心网络之间走白名单访问只开放必要的API端口。我在项目里见过因为AI服务异常导致闸机暂停服务的案例根因就是集成时图省事把AI直连进了闸机核心控制回路这种设计在轨道交通行业是不可以被接受的。4. 国产化工控平台的AI落地实战以龙芯2K3000为代表4.1 轨道交通AFC为什么越来越关注国产化算力平台做AFC系统集成的人这几年应该都有明显的感知新建线路和既有线改造项目里国产化算力平台的比重在持续提升。这里面有供应链稳定性的现实考虑。轨道交通设备的设计寿命是10到15年一条线路几十个站、几千台终端设备如果核心芯片的供货周期不稳定对后续维护和扩容的影响是毁灭性的。国产平台在这一点上有明显的优势长期供货保障更可靠。从技术层面看国产芯片这几年的能力提升也撑得起来了。过去大家担心的性能弱、工具链不完善、生态封闭这些老问题已经有了明显改善。龙芯的LoongArch指令集在工控领域逐渐打开局面OpenVINO、ONNX Runtime这类主流推理框架也完成了适配AI落地的技术障碍在降低。加上AFC设备对算力的需求本身不算极端——主要是嵌入式级的AI推理而不是高性能训练——这些都让国产平台在AFC场景里的可行性大幅提高。4.2 龙芯2K3000平台的性能画像与适配要点具体到龙芯2K3000这颗SoC它在AFC场景里是一款定位比较精准的产品。公开资料显示它面向工控和嵌入式应用基于LoongArch指令集架构多核心设计主频在GHz级别集成了显示控制器支持多屏输出这对AFC终端设备是刚需——一台售票机往往需要同时驱动触摸操作屏和面向乘客的展示屏。接口方面千兆以太网、多路USB、串口、CAN等工控外设接口是比较齐全的对接闸机控制器、纸币识别器、票卡读写器、打印机这些AFC标准外设没有明显短板。比较关键的一点是这颗SoC本身没有高算力的NPU所以在端侧做AI推理要靠两种方案一是纯CPU推理加SIMD指令优化适合MobileFaceNet、YOLOv8n这类轻量模型二是通过PCIe或USB外接AI加速卡适合对算力要求更高的任务。车站级边缘服务器可以选配性能更高的龙芯或同生态平台把视频分析和多路检测这类重任务放在边侧处理。4.3 在龙芯平台部署AI模型的实操过程与调优经验我在一个闸机AI模块迁移项目里把原先生成在x86平台上的PyTorch人脸识别模型迁移到龙芯平台的CPU上跑整个流程可以概括为四个步骤。第一步模型导出。在x86训练环境把PyTorch模型导出为ONNX格式固定输入尺寸和batch size这一步剔除掉训练才需要的动态shape和算子让推理图更干净。第二步模型量化。用ONNX Runtime的INT8量化工具拿一批实际场景数据做校准把FP32模型转成INT8模型。我实测下来INT8量化之后人脸特征提取模型体积缩小约四分之三推理速度提升约2到3倍识别精度基本持平。第三步交叉编译和部署准备。在x86开发机上用龙芯的交叉编译工具链把ONNX Runtime以及相关的图像预处理代码编译成LoongArch可执行文件再与模型文件一起拷贝到目标设备。第四步推理测试和调优。重点观察首帧时延和连续运行的稳定性。实际调优中还有几个值得分享的经验。数据预处理要和推理解耦图像缩放、归一化这些计算放到单独的线程里避免阻塞推理主流程。内存管理上AFC终端的内存有限推理时的输入输出缓冲区用内存池复用避免频繁malloc/free造成碎片。多线程并行时要留意锁的开销如果核心业务路径上锁竞争太高考虑用无锁队列或者读写锁优化。4.4 国产化平台迁移的坑点清单每一条都是真金白银换来的国产化迁移最大的坑不在芯片本身而在生态配套。我列一份踩坑清单后面做同类项目的人能少走不少弯路。外设驱动是第一个坎。AFC终端里的纸币识别器、票卡读写器、闸机电机驱动板很多是传统工控外设原厂驱动只提供x86版本没有LoArch版本。这个必须在项目启动早期就跟整机厂商和核心外设厂商确认适配计划不能等到系统联调了才发现驱动没有。嵌入式系统迁移也很关键原有应用如果是基于Windows的迁移到Linux加LoongArch后界面框架、串口通信、数据库驱动都要重新验证建议产品在架构设计阶段就采用Qt这类跨平台框架降低迁移成本。实时性同样要重点验证。闸机电机控制在某些环节对IO响应时延有要求如果在标准Linux内核上时序抖动太大就要考虑采用实时性增强方案或者把实时控制任务放在专门的控制板上不跟AI推理抢CPU。最后迁移后测试矩阵不能简化温度循环、温湿度、EMC电磁兼容、7乘24小时长稳测试都要按轨道交通标准重新过一遍不能因为芯片是新的就跳过可靠性验证。5. 试点到推广实施路径与真实踩坑记录5.1 试点车站怎么选三个标准缺一不可AI在AFC场景里落地最忌讳一上来就全线铺开。合理的路径是先选一个或几个试点站跑通验证技术可行性、运营配合度和真实效果再逐步扩大。选试点站我一般用三个标准。第一是业务价值要高选客流大、逃票现象相对突出、设备故障频率高的车站这种站AI效果容易体现也方便算清楚ROI。第二是网络条件要好AI边缘节点的运行依赖站级网络质量选一个网络基础好的站可以避免业务没验证出来先被网络问题捆住手脚。第三是运营团队要愿意配合AI系统上线初期一定会有误报、漏报和各种需要人工确认的情况如果车站团队抵触情绪大试点很容易被负面反馈淹没。5.2 数据冷启动与样本不均衡做AI落地最先碰到的两座山冷启动阶段最大的问题就是没标签。逃票检测场景里正常通行样本和逃票样本的比例可能差几千倍直接训练一个二分类模型模型会学成永远输出正常因为这样准确率也高达99.9%。解决思路是采用无监督或半监督方案作为冷启动先用目标检测加规则判定去发现闸机开启后通道内出现了多个行人这类强规则事件积累一批疑似逃票数据再由运营人员确认打标形成初始训练集。后续再通过重采样、合成样本等方式缓解类别不平衡。设备故障数据也存在类似问题。很多线路的历史运维数据并不完善故障标签缺失严重。我的做法是把规则引擎和无监督异常检测结合规则引擎先筛出明确故障故障码报警无监督模型负责发现未知的异常模式人工复核后反哺标签体系。这种方法跨几个项目验证下来性价比很高。5.3 模型上线不能一刀切灰度发布、A/B测试和快速回退AI模型上线和传统软件发布有一个很大区别模型的精度会漂移场景变化会导致效果下降。所以不能搞一次性全量切换必须有一套持续上线的机制。我们当时的做法是给每个模型建立版本档案记录训练数据集范围、训练日期、评测指标和变更说明。上线采用灰度策略先在一个车站或一条通道作为实验组运行和相邻通道的对照组做效果对比用通行效率、识别准确率、误报率、乘客投诉率这些指标来评估。最关键的是要预设回退预案。特别是和人脸过闸相关的模型在灰度期间如果出现误识率升高要能一键回退到上一版本整个过程乘客无感知。AFC系统是生产系统任何AI能力都必须是可插拔的这个问题上不能有任何侥幸心理。5.4 运维团队的转型以后不只是修闸机还要懂模型AI能力上线之后运维模式的变化可能比很多团队预想的更大。传统的AFC运维工程师主要修设备、换备件现在还要能看懂模型监控看板上的指标。我给团队的建议是建三块看板模型效果看板实时展示各站各场景的推理准确率、误报率、服务可用性设备健康看板直接展示预测性维护模型输出的设备健康分和剩余寿命建议运营效果看板把AI各项能力带来的客诉变化、逃票率变化、故障停机时长变化汇总到一张表上。另外建议建立每周复盘机制把AI告警的触发情况和人工确认结果做闭环比对。很多AI告警在第一次出现时会显得不正常但经过一段时间的运营反馈和模型迭代误报率会逐步降到可接受的范围。这个过程需要运营、算法、运维三方组成的小团队持续推进不能指望算法工程师远程丢一个模型就完事了。最后再分享一个我个人的体会AFCAI这种类型项目边界感比技术能力更重要。AI在轨道交通这类高可靠性行业里的定位永远是辅助决策而不是替代决策。人脸识别给你免密通行但闸机的开闸动作最终还是由AFC控制器执行AI给出设备维护建议但更换部件的指令还是走进工单流程。把这个边界想清楚项目的推进阻力会小一半。另外一个容易被低估的点是数据质量决定AI的上限。宁可花一半的精力做日志标准化和数据治理也不要急着把模型训练起来。轨道行业项目周期长、场景复杂把地基夯得足够实上面每一层才站得稳。