1. 自动扶梯智能监控的行业背景与核心需求自动扶梯这东西天天见商场、地铁、机场到处都是。但很多人不知道的是它其实是特种设备里事故率偏高的一类。我做过几年电梯物联网相关的项目接触过不少维保单位和监管平台的需求说实话大部分所谓的“智能监控”还停留在“装个摄像头远程看看”的阶段真正能把AI图像识别和功能安全两条线都跑通的方案少之又少。这个项目的核心命题就是解决一个很实际的矛盾AI识别要准、要快但扶梯是载人设备任何误判、漏判、系统死机都可能直接导致人身伤害。你不能像做互联网产品那样“先上线再迭代”也不能拿“模型准确率95%”这种指标来糊弄安全审查。所以标题里把“AI图像识别”和“功能安全”并列是有深意的——前者负责“看得见”后者负责“靠得住”。从行业需求来看自动扶梯的典型风险场景包括乘客逆行、摔倒、肢体被夹、异物卡入梳齿板、扶手带入口夹手、梯级缺失或塌陷等。传统方案靠红外对射、机械触点、人工巡检响应慢、覆盖窄、误报多。AI图像识别能大幅扩展感知维度但如果没有功能安全体系兜底AI本身就成了新的风险源。这个项目要做的就是让AI在安全框架内工作而不是让安全去迁就AI。适合阅读这篇内容的人做电梯物联网的嵌入式工程师、负责特种设备安全合规的技术负责人、想切入工业AI视觉的产品经理以及正在研究功能安全标准如何落地到实际设备上的开发者。我会尽量把标准要求、技术选型、实操细节和踩坑经验都摊开讲不绕弯子。2. 系统整体架构与方案选型逻辑2.1 为什么不能只做“AI摄像头报警”我见过太多方案本质上就是买几个网络摄像头接一个边缘盒子跑YOLO检测到人摔倒就推一条消息到管理后台。这种方案在演示环境里看着挺唬人但放到真实扶梯上问题立刻暴露光线变化导致误报、遮挡导致漏报、网络抖动导致消息丢失、盒子死机导致整个系统瘫痪。更致命的是没有任何机制能保证“AI判断失误时扶梯本身仍然是安全的”。功能安全的核心思想是安全不能依赖单一通道必须有冗余、有诊断、有失效导向安全的设计。所以这个系统的架构必须分层AI负责“增强感知”功能安全通道负责“兜底保护”两者独立又协同。2.2 三层架构设计我推荐的架构是三层感知层包括AI视觉模块摄像头边缘计算单元、传统安全传感器梳齿板触点、扶手带入口开关、梯级缺失检测等、以及扶梯控制器自身的状态信号运行方向、速度、制动状态。决策层分为AI推理通道和安全逻辑通道。AI通道输出风险等级和事件类型安全逻辑通道基于硬接线信号和经过认证的安全PLC执行急停、降速、报警等动作。执行层扶梯主控制器、制动器、声光报警器、远程监控平台。关键点在于AI通道的输出不能直接驱动安全动作。AI可以触发“预警”“减速建议”“通知维保”但真正的急停必须由安全逻辑通道独立判断。这样即使AI完全失效扶梯的安全等级不会降低。2.3 边缘计算 vs 云端推理这个选择我纠结过很久。云端推理的好处是算力无限、模型更新方便但扶梯场景对延迟极其敏感——从检测到摔倒到触发保护理想情况要在200ms内完成。网络延迟加上云端排队根本不可控。而且很多扶梯安装在地下室、地铁隧道网络稳定性堪忧。所以我的结论是必须边缘推理云端只做模型训练、数据汇总和远程管理。边缘设备选型上我倾向于带NPU的工业级边缘盒子比如瑞芯微RK3588或英伟达Jetson Orin Nano级别算力在10~40 TOPS之间能同时跑多路视频流和轻量级安全逻辑。功耗控制在15W以内无风扇设计适应扶梯机房的高温高湿环境。2.4 功能安全等级的确定自动扶梯属于特种设备功能安全等级通常参照IEC 61508或ISO 13849。对于急停保护功能一般要求达到PL dPerformance Level d或SIL 2。这意味着安全逻辑通道的硬件必须采用冗余架构比如双通道PLC或安全继电器。诊断覆盖率要高能检测到通道内部的故障。共因失效要控制比如双通道不能共用同一个电源或时钟。AI通道本身很难做到SIL 2认证所以它的定位是“非安全相关但安全增强”的功能。这个定位必须在系统设计文档里写清楚否则安全审查过不了。3. AI图像识别的核心技术点与实操细节3.1 检测目标定义与标注策略扶梯场景的AI检测不能笼统地做“行人检测”。我建议把目标拆成几类目标类别检测内容风险等级响应动作乘客状态站立、摔倒、逆行、攀爬扶手高预警减速肢体位置手/脚靠近梳齿板、扶手带入口高预警急停建议异物梯级上的大件物品、宠物、推车中预警设备状态梯级缺失、照明异常、盖板移位高急停通知维保标注的时候有个坑摔倒和弯腰捡东西在二维图像里非常像。我试过纯靠边界框姿态判断误报率很高。后来加入时序信息——连续多帧的姿态变化速度——才把误报压下来。所以标注时不仅要标单帧还要标时序片段让模型学习动作的连续性。3.2 模型选型与轻量化在边缘设备上跑模型不能太大。我实测下来YOLOv8n或YOLOv8s在RK3588上能跑到30fps以上精度也够用。但如果要同时做姿态估计就得用轻量级姿态模型比如MoveNet或RTMPose-tiny。这里有个经验不要追求单一模型解决所有问题。我见过有人试图用一个多任务模型同时做检测、姿态、分割结果在边缘设备上帧率掉到5fps完全没法用。更好的做法是级联先用轻量检测模型筛出感兴趣区域再对区域做精细姿态分析。这样大部分帧只跑检测算力消耗可控。3.3 光照与遮挡的工程处理扶梯场景的光照变化极其剧烈商场中庭的玻璃幕墙会导致逆光和光斑地铁站的光线偏暗且色温不稳室外扶梯还有昼夜交替。我踩过的坑是模型在实验室准确率98%到现场直接掉到70%。解决办法有几个层面硬件层面选用宽动态范围摄像头支持120dB以上WDR配合自动曝光和自动白平衡。镜头选广角但畸变可控的避免边缘区域拉伸导致检测失效。数据层面训练集必须包含各种光照条件下的现场采集数据不能只用公开数据集。我通常会要求现场采集至少一周的连续视频覆盖早中晚和不同天气。算法层面加入直方图均衡化或自适应伽马校正作为预处理但要注意这些操作不能引入额外延迟。实测在NPU上做预处理比在CPU上快3倍以上。遮挡问题更麻烦。扶梯上人挤人的时候目标互相遮挡检测框会合并或丢失。我的做法是降低单帧检测的权重提高时序跟踪的权重。用ByteTrack或OC-SORT做多目标跟踪即使某一帧检测丢了靠轨迹预测也能维持几帧给安全逻辑留出反应时间。3.4 误报与漏报的平衡安全场景下漏报比误报更致命但误报太多会导致系统被维保人员关掉。我的经验是分级响应。低置信度检测只记录不报警中置信度触发预警通知高置信度才触发减速或急停建议。置信度阈值不是拍脑袋定的要用现场数据做ROC曲线分析找到漏报率低于0.1%对应的阈值。另外多传感器融合能显著降低误报。比如AI检测到“疑似摔倒”同时梳齿板触点没有触发、扶手带速度正常那大概率是误报可以只记录不动作。如果AI检测到摔倒且扶梯速度异常波动那就必须立即响应。4. 功能安全体系在扶梯监控中的落地4.1 安全生命周期与文档要求功能安全不是买个安全PLC就完事了它是一整套生命周期管理。从概念阶段就要做危害分析HAZOP、风险评估确定安全功能和安全完整性等级。然后才是设计、实现、验证、确认、运行维护。我参与过一个项目前期没做完整的危害分析直接上代码结果安全审查时被要求补文档整整拖了三个月。所以我的建议是从第一天就按安全生命周期建文档。关键文档包括安全需求规格书SRS安全概念说明书硬件安全手册软件安全需求与架构设计验证与确认报告安全案例Safety Case这些文档不是形式主义它们直接决定了系统能不能通过第三方认证。4.2 安全逻辑通道的设计安全逻辑通道我推荐用经过认证的安全PLC比如西门子S7-1500F或皮尔兹PSS 4000。输入包括急停按钮双通道梳齿板触点双通道扶手带入口开关双通道梯级缺失检测双通道AI系统的“高置信度风险”信号单通道作为增强输入输出包括制动器控制双通道声光报警远程通知关键设计原则AI信号只能作为“建议”输入不能直接参与安全逻辑的与/或运算。安全PLC的程序里AI信号的作用是“如果AI也认为有风险则缩短响应时间”而不是“AI说有风险就急停”。4.3 诊断与失效导向安全功能安全要求系统能诊断自身故障并在故障时导向安全状态。对于这个系统需要诊断的故障包括摄像头离线或画面冻结边缘计算单元死机或过热AI推理超时安全PLC通道间不一致制动器反馈异常诊断到故障后系统应该进入安全状态。对于扶梯安全状态通常是“停止运行并保持制动”。但这里有个实际问题如果AI模块故障扶梯要不要停我的判断是如果AI只是增强功能故障时不应影响扶梯基本运行但必须发出明确的“AI功能降级”告警并通知维保。如果安全逻辑通道故障那就必须停梯。4.4 软件组件的鉴定与认证热词里提到了“ISO 26262中功能安全开发的软件组件鉴定报告”虽然ISO 26262是汽车行业的但思路可以借鉴。对于扶梯AI软件如果它被归类为安全相关组件就需要做软件鉴定。鉴定内容包括需求追溯矩阵静态代码分析报告单元测试和集成测试覆盖率边界值和等价类测试资源使用分析CPU、内存、栈深度如果AI软件被归类为非安全相关那鉴定要求可以放宽但必须在安全案例中说明“为什么它的失效不会导致安全功能失效”。这个论证过程本身就是功能安全的核心工作。5. 实操部署与现场调试经验5.1 摄像头安装位置与角度摄像头装哪里直接决定AI能不能用。我试过几种方案扶梯入口上方能看清乘客进入状态但看不到梯级中段。扶梯侧面能看清梯级和梳齿板但遮挡严重。扶梯出口上方能看清离开状态但对入口风险响应太晚。最终我采用的是入口中段双摄像头方案。入口摄像头负责检测进入状态和逆行中段摄像头负责检测摔倒和肢体位置。两个摄像头的数据在边缘盒子里做时间同步融合判断。安装角度要注意俯角控制在30~45度之间。太低会被乘客头部遮挡太高会导致透视畸变严重。镜头焦距选2.8mm或4mm根据扶梯长度调整。5.2 边缘设备的散热与防护扶梯机房的环境比想象中恶劣夏天温度能到50度以上湿度大还有粉尘。我一开始用消费级边缘盒子结果夏天频繁死机。后来换成工业级无风扇设计IP40以上防护工作温度-20~70度才稳定下来。散热方面不要用风扇风扇是故障率最高的部件。用大面积铝制散热片导热硅脂把热量导到金属外壳上。如果机房温度实在太高可以考虑加装半导体制冷片但功耗会增加。5.3 网络与数据回传边缘设备本地存储至少保留7天视频和事件记录防止网络中断导致数据丢失。回传策略我建议事件视频片段前后各10秒优先回传统计数据和告警信息实时回传原始视频流按需回传平时只传低码率预览网络协议用MQTT over TLS保证传输安全。如果现场没有有线网络可以用4G/5G模块但要注意流量成本和信号稳定性。5.4 现场调试的步骤现场调试我一般按这个顺序硬件检查摄像头画面是否清晰、边缘盒子是否正常启动、安全PLC通道是否一致。网络配置IP地址、端口、TLS证书、MQTT主题。AI模型验证用现场录制的视频回放测试统计检测率和误报率。安全逻辑测试模拟急停、梳齿板触发、AI高置信度信号验证响应时间和动作正确性。联调AI触发预警观察安全PLC是否正确响应远程平台是否收到消息。试运行至少连续运行72小时记录所有异常和误报。调试中最容易忽略的是时间同步。AI事件的时间戳和安全PLC的时间戳必须对齐否则事后分析根本对不上。我通常用NTP统一对时精度要求在10ms以内。6. 常见问题与排查技巧实录6.1 AI误报频繁怎么办这是最常见的问题。排查思路先看误报的类型是光照变化引起的还是遮挡引起的还是模型本身分类错误。如果是光照检查摄像头WDR设置增加现场光照数据重新训练。如果是遮挡调整摄像头角度或者增加跟踪算法权重。如果是分类错误检查标注质量特别是容易混淆的类别如摔倒vs弯腰。我踩过的一个坑模型把“穿深色衣服的人蹲下”误判为摔倒。后来在训练集里专门加了大量蹲下、系鞋带、捡东西的负样本误报率从每天20次降到2次以下。6.2 边缘设备频繁重启原因通常有三类过热、电源不稳、软件内存泄漏。排查方法看设备日志确认重启前是否有温度告警或电压异常。用红外测温枪测外壳温度超过70度就要加强散热。检查电源是否满足峰值功耗要求边缘盒子启动瞬间电流可能比额定高50%。如果是内存泄漏用valgrind或类似工具分析重点检查视频解码和推理循环。6.3 安全PLC报通道不一致这是功能安全系统特有的问题。双通道设计要求两个通道的信号在很短时间内一致如果偏差超过设定值就报故障。常见原因输入触点氧化或接触不良通道间接线长度差异过大导致延迟不同安全PLC的滤波时间设置过短解决办法清洁触点、调整接线、适当增加滤波时间。但滤波时间不能太长否则会影响响应速度。一般设置在10~50ms之间。6.4 远程平台收不到告警排查顺序边缘设备是否联网MQTT broker是否正常TLS证书是否过期主题订阅是否正确防火墙是否拦截我遇到过最隐蔽的问题是边缘设备的时间不对导致TLS握手失败。因为TLS证书验证依赖系统时间时间偏差超过几分钟就会拒绝连接。所以NTP对时是必须的。6.5 常见问题速查表问题现象可能原因排查方法解决措施AI误报多光照/遮挡/标注差回放视频分析补数据/调角度/改模型设备重启过热/电源/内存看日志/测温/测电压加强散热/换电源/修泄漏PLC通道故障触点/接线/滤波测通断/查接线/调参数清洁/调整/重设平台无告警网络/证书/主题逐层ping/查日志修复网络/更新证书推理延迟高模型大/算力不足测帧率/看CPU占用换轻量模型/升级硬件7. 安全标准要求与合规路径7.1 适用的标准体系自动扶梯智能监控涉及的标准不少主要分几类特种设备安全规范国内有TSG T7005《自动扶梯和自动人行道监督检验规则》对安全保护装置有明确要求。功能安全标准IEC 61508通用、ISO 13849机械安全控制系统、IEC 62061机械安全电气系统。电磁兼容IEC 61000系列确保设备在扶梯电机、变频器干扰下正常工作。AI相关标准ISO/IEC TR 5469AI功能安全、ISO/IEC 23894AI风险管理。这些标准不是孤立的合规路径要把它们串起来。我的做法是先按特种设备规范确定基本安全要求再用功能安全标准设计安全逻辑最后用AI标准评估AI模块的风险。7.2 安全案例的编写要点安全案例是证明系统达到安全要求的核心文档。编写时要注意论证结构清晰从危害分析到安全需求再到设计实现和验证每一步都要有追溯。证据充分测试报告、分析报告、认证证书都要作为附件。假设明确比如“假设维保人员按手册定期检查”这种假设要写清楚并说明如果假设不成立会有什么后果。残余风险说明任何系统都有残余风险要明确说明并给出缓解措施。我写过的一份安全案例大概80页其中一半是测试证据。审查方最关注的是你怎么证明AI失效时系统仍然安全。这个论证必须无懈可击。7.3 第三方认证的流程如果项目需要第三方认证流程一般是提交安全需求规格书和安全概念认证机构评审提出整改意见提交详细设计和验证报告现场测试见证颁发认证证书整个过程通常需要6~12个月费用从几十万到上百万不等。如果只是内部合规可以简化流程但核心文档和测试不能省。8. 系统扩展与未来演进方向8.1 从单梯监控到群梯管理单台扶梯的智能监控做完了下一步自然是扩展到整个站点或商场的群梯管理。这时候需要考虑统一的数据平台支持多设备接入跨扶梯的风险关联分析比如某台扶梯频繁报警可能是设计或安装问题维保调度的优化根据报警频率和类型自动派单我做过一个地铁站的群梯管理项目12台扶梯接入同一个平台维保响应时间从平均4小时降到1.5小时。8.2 预测性维护的引入AI图像识别不仅能做安全监控还能做预测性维护。比如通过分析梯级表面磨损图像预测更换周期通过扶手带运行视频检测异常抖动或偏移通过梳齿板异物频率评估清洁需求这些功能不需要功能安全认证可以作为增值服务单独提供。8.3 大模型与多模态融合热词里提到了“ai大模型”和“多模态”这在扶梯场景也有想象空间。比如用视觉语言模型做零样本异常检测不需要针对每个场景重新训练。但大模型的推理延迟和算力需求目前还不适合边缘部署短期内还是以轻量模型为主。我的判断是未来3~5年边缘AI芯片算力会继续提升大模型蒸馏和量化技术也会成熟到时候在边缘跑多模态模型不是梦。但功能安全的框架不会变安全逻辑通道永远要独立于AI通道。8.4 标准化与互联互通目前扶梯智能监控还没有统一的行业标准各厂家协议不互通。我希望能推动建立统一的数据接口和安全评估规范让不同品牌的设备能接入同一个平台。这需要行业组织、认证机构和企业的共同努力。我个人在实际项目中的体会是功能安全不是成本而是竞争力。同样做AI监控能通过安全认证的方案在招投标和客户信任度上优势明显。前期多花的时间和费用后期都会以订单和口碑的形式回来。最后分享一个小技巧如果预算有限可以先做非安全相关的AI预警功能积累现场数据和运行经验等模式成熟后再升级到功能安全版本。这样风险可控迭代也快。
自动扶梯AI图像识别与功能安全融合的智能监控系统设计与实践
1. 自动扶梯智能监控的行业背景与核心需求自动扶梯这东西天天见商场、地铁、机场到处都是。但很多人不知道的是它其实是特种设备里事故率偏高的一类。我做过几年电梯物联网相关的项目接触过不少维保单位和监管平台的需求说实话大部分所谓的“智能监控”还停留在“装个摄像头远程看看”的阶段真正能把AI图像识别和功能安全两条线都跑通的方案少之又少。这个项目的核心命题就是解决一个很实际的矛盾AI识别要准、要快但扶梯是载人设备任何误判、漏判、系统死机都可能直接导致人身伤害。你不能像做互联网产品那样“先上线再迭代”也不能拿“模型准确率95%”这种指标来糊弄安全审查。所以标题里把“AI图像识别”和“功能安全”并列是有深意的——前者负责“看得见”后者负责“靠得住”。从行业需求来看自动扶梯的典型风险场景包括乘客逆行、摔倒、肢体被夹、异物卡入梳齿板、扶手带入口夹手、梯级缺失或塌陷等。传统方案靠红外对射、机械触点、人工巡检响应慢、覆盖窄、误报多。AI图像识别能大幅扩展感知维度但如果没有功能安全体系兜底AI本身就成了新的风险源。这个项目要做的就是让AI在安全框架内工作而不是让安全去迁就AI。适合阅读这篇内容的人做电梯物联网的嵌入式工程师、负责特种设备安全合规的技术负责人、想切入工业AI视觉的产品经理以及正在研究功能安全标准如何落地到实际设备上的开发者。我会尽量把标准要求、技术选型、实操细节和踩坑经验都摊开讲不绕弯子。2. 系统整体架构与方案选型逻辑2.1 为什么不能只做“AI摄像头报警”我见过太多方案本质上就是买几个网络摄像头接一个边缘盒子跑YOLO检测到人摔倒就推一条消息到管理后台。这种方案在演示环境里看着挺唬人但放到真实扶梯上问题立刻暴露光线变化导致误报、遮挡导致漏报、网络抖动导致消息丢失、盒子死机导致整个系统瘫痪。更致命的是没有任何机制能保证“AI判断失误时扶梯本身仍然是安全的”。功能安全的核心思想是安全不能依赖单一通道必须有冗余、有诊断、有失效导向安全的设计。所以这个系统的架构必须分层AI负责“增强感知”功能安全通道负责“兜底保护”两者独立又协同。2.2 三层架构设计我推荐的架构是三层感知层包括AI视觉模块摄像头边缘计算单元、传统安全传感器梳齿板触点、扶手带入口开关、梯级缺失检测等、以及扶梯控制器自身的状态信号运行方向、速度、制动状态。决策层分为AI推理通道和安全逻辑通道。AI通道输出风险等级和事件类型安全逻辑通道基于硬接线信号和经过认证的安全PLC执行急停、降速、报警等动作。执行层扶梯主控制器、制动器、声光报警器、远程监控平台。关键点在于AI通道的输出不能直接驱动安全动作。AI可以触发“预警”“减速建议”“通知维保”但真正的急停必须由安全逻辑通道独立判断。这样即使AI完全失效扶梯的安全等级不会降低。2.3 边缘计算 vs 云端推理这个选择我纠结过很久。云端推理的好处是算力无限、模型更新方便但扶梯场景对延迟极其敏感——从检测到摔倒到触发保护理想情况要在200ms内完成。网络延迟加上云端排队根本不可控。而且很多扶梯安装在地下室、地铁隧道网络稳定性堪忧。所以我的结论是必须边缘推理云端只做模型训练、数据汇总和远程管理。边缘设备选型上我倾向于带NPU的工业级边缘盒子比如瑞芯微RK3588或英伟达Jetson Orin Nano级别算力在10~40 TOPS之间能同时跑多路视频流和轻量级安全逻辑。功耗控制在15W以内无风扇设计适应扶梯机房的高温高湿环境。2.4 功能安全等级的确定自动扶梯属于特种设备功能安全等级通常参照IEC 61508或ISO 13849。对于急停保护功能一般要求达到PL dPerformance Level d或SIL 2。这意味着安全逻辑通道的硬件必须采用冗余架构比如双通道PLC或安全继电器。诊断覆盖率要高能检测到通道内部的故障。共因失效要控制比如双通道不能共用同一个电源或时钟。AI通道本身很难做到SIL 2认证所以它的定位是“非安全相关但安全增强”的功能。这个定位必须在系统设计文档里写清楚否则安全审查过不了。3. AI图像识别的核心技术点与实操细节3.1 检测目标定义与标注策略扶梯场景的AI检测不能笼统地做“行人检测”。我建议把目标拆成几类目标类别检测内容风险等级响应动作乘客状态站立、摔倒、逆行、攀爬扶手高预警减速肢体位置手/脚靠近梳齿板、扶手带入口高预警急停建议异物梯级上的大件物品、宠物、推车中预警设备状态梯级缺失、照明异常、盖板移位高急停通知维保标注的时候有个坑摔倒和弯腰捡东西在二维图像里非常像。我试过纯靠边界框姿态判断误报率很高。后来加入时序信息——连续多帧的姿态变化速度——才把误报压下来。所以标注时不仅要标单帧还要标时序片段让模型学习动作的连续性。3.2 模型选型与轻量化在边缘设备上跑模型不能太大。我实测下来YOLOv8n或YOLOv8s在RK3588上能跑到30fps以上精度也够用。但如果要同时做姿态估计就得用轻量级姿态模型比如MoveNet或RTMPose-tiny。这里有个经验不要追求单一模型解决所有问题。我见过有人试图用一个多任务模型同时做检测、姿态、分割结果在边缘设备上帧率掉到5fps完全没法用。更好的做法是级联先用轻量检测模型筛出感兴趣区域再对区域做精细姿态分析。这样大部分帧只跑检测算力消耗可控。3.3 光照与遮挡的工程处理扶梯场景的光照变化极其剧烈商场中庭的玻璃幕墙会导致逆光和光斑地铁站的光线偏暗且色温不稳室外扶梯还有昼夜交替。我踩过的坑是模型在实验室准确率98%到现场直接掉到70%。解决办法有几个层面硬件层面选用宽动态范围摄像头支持120dB以上WDR配合自动曝光和自动白平衡。镜头选广角但畸变可控的避免边缘区域拉伸导致检测失效。数据层面训练集必须包含各种光照条件下的现场采集数据不能只用公开数据集。我通常会要求现场采集至少一周的连续视频覆盖早中晚和不同天气。算法层面加入直方图均衡化或自适应伽马校正作为预处理但要注意这些操作不能引入额外延迟。实测在NPU上做预处理比在CPU上快3倍以上。遮挡问题更麻烦。扶梯上人挤人的时候目标互相遮挡检测框会合并或丢失。我的做法是降低单帧检测的权重提高时序跟踪的权重。用ByteTrack或OC-SORT做多目标跟踪即使某一帧检测丢了靠轨迹预测也能维持几帧给安全逻辑留出反应时间。3.4 误报与漏报的平衡安全场景下漏报比误报更致命但误报太多会导致系统被维保人员关掉。我的经验是分级响应。低置信度检测只记录不报警中置信度触发预警通知高置信度才触发减速或急停建议。置信度阈值不是拍脑袋定的要用现场数据做ROC曲线分析找到漏报率低于0.1%对应的阈值。另外多传感器融合能显著降低误报。比如AI检测到“疑似摔倒”同时梳齿板触点没有触发、扶手带速度正常那大概率是误报可以只记录不动作。如果AI检测到摔倒且扶梯速度异常波动那就必须立即响应。4. 功能安全体系在扶梯监控中的落地4.1 安全生命周期与文档要求功能安全不是买个安全PLC就完事了它是一整套生命周期管理。从概念阶段就要做危害分析HAZOP、风险评估确定安全功能和安全完整性等级。然后才是设计、实现、验证、确认、运行维护。我参与过一个项目前期没做完整的危害分析直接上代码结果安全审查时被要求补文档整整拖了三个月。所以我的建议是从第一天就按安全生命周期建文档。关键文档包括安全需求规格书SRS安全概念说明书硬件安全手册软件安全需求与架构设计验证与确认报告安全案例Safety Case这些文档不是形式主义它们直接决定了系统能不能通过第三方认证。4.2 安全逻辑通道的设计安全逻辑通道我推荐用经过认证的安全PLC比如西门子S7-1500F或皮尔兹PSS 4000。输入包括急停按钮双通道梳齿板触点双通道扶手带入口开关双通道梯级缺失检测双通道AI系统的“高置信度风险”信号单通道作为增强输入输出包括制动器控制双通道声光报警远程通知关键设计原则AI信号只能作为“建议”输入不能直接参与安全逻辑的与/或运算。安全PLC的程序里AI信号的作用是“如果AI也认为有风险则缩短响应时间”而不是“AI说有风险就急停”。4.3 诊断与失效导向安全功能安全要求系统能诊断自身故障并在故障时导向安全状态。对于这个系统需要诊断的故障包括摄像头离线或画面冻结边缘计算单元死机或过热AI推理超时安全PLC通道间不一致制动器反馈异常诊断到故障后系统应该进入安全状态。对于扶梯安全状态通常是“停止运行并保持制动”。但这里有个实际问题如果AI模块故障扶梯要不要停我的判断是如果AI只是增强功能故障时不应影响扶梯基本运行但必须发出明确的“AI功能降级”告警并通知维保。如果安全逻辑通道故障那就必须停梯。4.4 软件组件的鉴定与认证热词里提到了“ISO 26262中功能安全开发的软件组件鉴定报告”虽然ISO 26262是汽车行业的但思路可以借鉴。对于扶梯AI软件如果它被归类为安全相关组件就需要做软件鉴定。鉴定内容包括需求追溯矩阵静态代码分析报告单元测试和集成测试覆盖率边界值和等价类测试资源使用分析CPU、内存、栈深度如果AI软件被归类为非安全相关那鉴定要求可以放宽但必须在安全案例中说明“为什么它的失效不会导致安全功能失效”。这个论证过程本身就是功能安全的核心工作。5. 实操部署与现场调试经验5.1 摄像头安装位置与角度摄像头装哪里直接决定AI能不能用。我试过几种方案扶梯入口上方能看清乘客进入状态但看不到梯级中段。扶梯侧面能看清梯级和梳齿板但遮挡严重。扶梯出口上方能看清离开状态但对入口风险响应太晚。最终我采用的是入口中段双摄像头方案。入口摄像头负责检测进入状态和逆行中段摄像头负责检测摔倒和肢体位置。两个摄像头的数据在边缘盒子里做时间同步融合判断。安装角度要注意俯角控制在30~45度之间。太低会被乘客头部遮挡太高会导致透视畸变严重。镜头焦距选2.8mm或4mm根据扶梯长度调整。5.2 边缘设备的散热与防护扶梯机房的环境比想象中恶劣夏天温度能到50度以上湿度大还有粉尘。我一开始用消费级边缘盒子结果夏天频繁死机。后来换成工业级无风扇设计IP40以上防护工作温度-20~70度才稳定下来。散热方面不要用风扇风扇是故障率最高的部件。用大面积铝制散热片导热硅脂把热量导到金属外壳上。如果机房温度实在太高可以考虑加装半导体制冷片但功耗会增加。5.3 网络与数据回传边缘设备本地存储至少保留7天视频和事件记录防止网络中断导致数据丢失。回传策略我建议事件视频片段前后各10秒优先回传统计数据和告警信息实时回传原始视频流按需回传平时只传低码率预览网络协议用MQTT over TLS保证传输安全。如果现场没有有线网络可以用4G/5G模块但要注意流量成本和信号稳定性。5.4 现场调试的步骤现场调试我一般按这个顺序硬件检查摄像头画面是否清晰、边缘盒子是否正常启动、安全PLC通道是否一致。网络配置IP地址、端口、TLS证书、MQTT主题。AI模型验证用现场录制的视频回放测试统计检测率和误报率。安全逻辑测试模拟急停、梳齿板触发、AI高置信度信号验证响应时间和动作正确性。联调AI触发预警观察安全PLC是否正确响应远程平台是否收到消息。试运行至少连续运行72小时记录所有异常和误报。调试中最容易忽略的是时间同步。AI事件的时间戳和安全PLC的时间戳必须对齐否则事后分析根本对不上。我通常用NTP统一对时精度要求在10ms以内。6. 常见问题与排查技巧实录6.1 AI误报频繁怎么办这是最常见的问题。排查思路先看误报的类型是光照变化引起的还是遮挡引起的还是模型本身分类错误。如果是光照检查摄像头WDR设置增加现场光照数据重新训练。如果是遮挡调整摄像头角度或者增加跟踪算法权重。如果是分类错误检查标注质量特别是容易混淆的类别如摔倒vs弯腰。我踩过的一个坑模型把“穿深色衣服的人蹲下”误判为摔倒。后来在训练集里专门加了大量蹲下、系鞋带、捡东西的负样本误报率从每天20次降到2次以下。6.2 边缘设备频繁重启原因通常有三类过热、电源不稳、软件内存泄漏。排查方法看设备日志确认重启前是否有温度告警或电压异常。用红外测温枪测外壳温度超过70度就要加强散热。检查电源是否满足峰值功耗要求边缘盒子启动瞬间电流可能比额定高50%。如果是内存泄漏用valgrind或类似工具分析重点检查视频解码和推理循环。6.3 安全PLC报通道不一致这是功能安全系统特有的问题。双通道设计要求两个通道的信号在很短时间内一致如果偏差超过设定值就报故障。常见原因输入触点氧化或接触不良通道间接线长度差异过大导致延迟不同安全PLC的滤波时间设置过短解决办法清洁触点、调整接线、适当增加滤波时间。但滤波时间不能太长否则会影响响应速度。一般设置在10~50ms之间。6.4 远程平台收不到告警排查顺序边缘设备是否联网MQTT broker是否正常TLS证书是否过期主题订阅是否正确防火墙是否拦截我遇到过最隐蔽的问题是边缘设备的时间不对导致TLS握手失败。因为TLS证书验证依赖系统时间时间偏差超过几分钟就会拒绝连接。所以NTP对时是必须的。6.5 常见问题速查表问题现象可能原因排查方法解决措施AI误报多光照/遮挡/标注差回放视频分析补数据/调角度/改模型设备重启过热/电源/内存看日志/测温/测电压加强散热/换电源/修泄漏PLC通道故障触点/接线/滤波测通断/查接线/调参数清洁/调整/重设平台无告警网络/证书/主题逐层ping/查日志修复网络/更新证书推理延迟高模型大/算力不足测帧率/看CPU占用换轻量模型/升级硬件7. 安全标准要求与合规路径7.1 适用的标准体系自动扶梯智能监控涉及的标准不少主要分几类特种设备安全规范国内有TSG T7005《自动扶梯和自动人行道监督检验规则》对安全保护装置有明确要求。功能安全标准IEC 61508通用、ISO 13849机械安全控制系统、IEC 62061机械安全电气系统。电磁兼容IEC 61000系列确保设备在扶梯电机、变频器干扰下正常工作。AI相关标准ISO/IEC TR 5469AI功能安全、ISO/IEC 23894AI风险管理。这些标准不是孤立的合规路径要把它们串起来。我的做法是先按特种设备规范确定基本安全要求再用功能安全标准设计安全逻辑最后用AI标准评估AI模块的风险。7.2 安全案例的编写要点安全案例是证明系统达到安全要求的核心文档。编写时要注意论证结构清晰从危害分析到安全需求再到设计实现和验证每一步都要有追溯。证据充分测试报告、分析报告、认证证书都要作为附件。假设明确比如“假设维保人员按手册定期检查”这种假设要写清楚并说明如果假设不成立会有什么后果。残余风险说明任何系统都有残余风险要明确说明并给出缓解措施。我写过的一份安全案例大概80页其中一半是测试证据。审查方最关注的是你怎么证明AI失效时系统仍然安全。这个论证必须无懈可击。7.3 第三方认证的流程如果项目需要第三方认证流程一般是提交安全需求规格书和安全概念认证机构评审提出整改意见提交详细设计和验证报告现场测试见证颁发认证证书整个过程通常需要6~12个月费用从几十万到上百万不等。如果只是内部合规可以简化流程但核心文档和测试不能省。8. 系统扩展与未来演进方向8.1 从单梯监控到群梯管理单台扶梯的智能监控做完了下一步自然是扩展到整个站点或商场的群梯管理。这时候需要考虑统一的数据平台支持多设备接入跨扶梯的风险关联分析比如某台扶梯频繁报警可能是设计或安装问题维保调度的优化根据报警频率和类型自动派单我做过一个地铁站的群梯管理项目12台扶梯接入同一个平台维保响应时间从平均4小时降到1.5小时。8.2 预测性维护的引入AI图像识别不仅能做安全监控还能做预测性维护。比如通过分析梯级表面磨损图像预测更换周期通过扶手带运行视频检测异常抖动或偏移通过梳齿板异物频率评估清洁需求这些功能不需要功能安全认证可以作为增值服务单独提供。8.3 大模型与多模态融合热词里提到了“ai大模型”和“多模态”这在扶梯场景也有想象空间。比如用视觉语言模型做零样本异常检测不需要针对每个场景重新训练。但大模型的推理延迟和算力需求目前还不适合边缘部署短期内还是以轻量模型为主。我的判断是未来3~5年边缘AI芯片算力会继续提升大模型蒸馏和量化技术也会成熟到时候在边缘跑多模态模型不是梦。但功能安全的框架不会变安全逻辑通道永远要独立于AI通道。8.4 标准化与互联互通目前扶梯智能监控还没有统一的行业标准各厂家协议不互通。我希望能推动建立统一的数据接口和安全评估规范让不同品牌的设备能接入同一个平台。这需要行业组织、认证机构和企业的共同努力。我个人在实际项目中的体会是功能安全不是成本而是竞争力。同样做AI监控能通过安全认证的方案在招投标和客户信任度上优势明显。前期多花的时间和费用后期都会以订单和口碑的形式回来。最后分享一个小技巧如果预算有限可以先做非安全相关的AI预警功能积累现场数据和运行经验等模式成熟后再升级到功能安全版本。这样风险可控迭代也快。
