AI图像识别与功能安全在自动扶梯智能监控中的应用实践

1. 项目背景与整体设计思路1.1 核心需求解析自动扶梯的运维和安全保障说实话一直是个矛盾体。一方面扶梯属于特种设备每天高负荷运转承载量巨大尤其在商场、地铁站、机场这种人流密集场所运行工况极其复杂另一方面传统维保手段以定期巡检和事后响应为主很难做到全天候实时监控。更麻烦的是扶梯的危险往往在几秒内发生——比如乘客逆行、摔倒、行李卡住梳齿板、儿童在梯级上攀爬这些场景靠监控室里的保安盯着几十路画面去发现基本不现实。这就是AI图像识别介入的天然场景。用摄像头加算法替代人眼自动识别扶梯区域内的异常行为再把结果接入扶梯控制系统实现急停或者降速。听起来不复杂但真正落地的时候会发现从“看见异常”到“安全停车”之间隔着一条巨大的鸿沟。这条鸿沟叫功能安全也就是要保证AI系统判断错误或者失效时整套设备依然处于安全状态。我今年参与了一个基于AI图像识别与功能安全的自动扶梯智能监控项目历时八个月从实验室Demo做到现场试运行。整个过程踩了不少坑也积累了一些可供参考的经验觉得值得整理出来。这篇文章不会只讲算法效果多好重点放在两部分一是图像识别模块怎么选型、怎么训练、怎么适配现场环境二是功能安全链路怎么设计、怎么满足标准和监管要求。适合正在做类似智能化改造项目的工程师、电梯厂商的技术人员以及负责特种设备数字化建设的运维团队参考。1.2 系统整体架构先给整个系统画个轮廓这里用文字描述实时视频流采集扶梯出入口梯级区域 ↓ AI边缘计算单元图像识别推理 ↓ 行为事件输出摔倒、逆行、携带儿童车、异物侵占等 ↓ 安全控制单元功能安全逻辑判断 ↓ 扶梯控制系统接口急停、降速、报警联动 ↓ 远程监控平台事件推送、运维工单、视频复核这个链路里的关键点在于AI部分和功能安全部分在物理上要松散耦合但逻辑上必须严格握手。为什么这么设计因为AI图像识别的输出本质上是概率性的不可能做到100%准确而功能安全要求的是确定性逻辑。所以整个系统不能简单地把AI输出直接接到安全回路里必须在中间加一层带安全认证的控制逻辑把AI事件转换为经过表决和时序判断的安全指令。这种分层思路在行业里比较常见它解决了两个问题一是算法模型可以持续迭代不影响已经过认证的安全链路二是即使AI模块完全失效比如算力卡死、网络中断扶梯本身最基本的运行安全还是由原有的安全部件保障系统退回普通模式不会因为智能化改造而降低原有安全等级。2. 图像识别模块的设计与实现2.1 摄像头选型与安装点位摄像头是整个系统的眼睛选型和安装直接决定后面算法能不能跑起来。我实测下来需要注意几个关键参数不是随便拿个网络枪机就行。首先帧率至少要在15fps以上低于10fps会导致快速动作比如乘客摔倒那一下产生严重的运动模糊和跳帧后续算法很难稳定检出。我用的是海康的工业面阵相机加定焦镜头分辨率200万像素帧率设置在20fps。为什么不用更高分辨率对算法来说200万像素检测扶梯出入口的区域已经够了分辨率越高对边缘计算单元的带宽和解码压力越大得不偿失。其次是安装点位。这里有个很深的教训最初我们参照安防监控的习惯把摄像头装在扶梯正前方高处视角是俯视的正面。后来发现这种角度对于摔倒检测基本无效——人体摔倒瞬间的形态特征被正前方视角压缩得很厉害。后来改成了在扶梯出入口侧面45度角安装既能拍到踏入扶梯前的完整人体姿态又能覆盖梯级运行方向前2到3个梯级的区域效果立刻好了很多。现场安装时还要注意扶梯本身的照明条件。商场环境通常照明充足但地铁站和户外连廊的扶梯会面临逆光、夜间低照度等问题。逆光场景下建议用宽动态WDR摄像头夜间则需要带补光。不过补光灯的位置要调试好否则会产生反光反而干扰检测。我这边调试时发现红外补光灯装在摄像头下方10厘米处、且加一个遮光罩能显著减少梯级金属表面的镜面反射干扰。2.2 算法选型与模型训练算法选型上主流方案是目标检测加行为分类的串联结构。具体来说先用目标检测模型在每一帧图像中定位人体然后通过时序模型比如LSTM或3D卷积网络分析连续帧中人体关键点序列的变化来判断当前行为类型。实际项目里我采用了YOLOv5加自研的轻量级姿态分类模型。为什么不直接上基于骨骼关键点的姿态估计因为现场算力有限我们边缘设备用的是Jetson Orin Nano跑一个完整的HRNet类姿态估计模型帧率顶多8到10fps达不到要求。YOLOv5的推理速度在TensorRT加速下可以做到25fps以上给后续行为分类留出了预算。训练数据是最花时间也最影响效果的部分。这里分享一下我们的数据策略公开数据集比如COCO、HAGRID这类摔倒检测数据集只能作为预训练基础真正要投产必须采集现场数据。我们在地铁站和商场各选了两台扶梯架上临时的数据采集系统连续采集了7天共获得大约120小时视频。把其中有行为差异的片段截取出来标注了大约3万多帧的样本。具体的行为类别我们定义了7类摔倒、逆行、奔跑、携带婴儿车、携带大件行李、倚靠扶梯侧板、攀爬扶梯。这7类都是实际排查电梯事故报告中高频出现的原因不做全行为识别避免样本不够导致模型发散。训练过程有几个坑值得提一下。第一摔倒样本极度不平衡正常行走样本占九成以上我们通过数据增强随机裁剪、旋转、色彩扰动把摔倒样本扩充了三倍。第二扶梯场景和普通场景差异很大金属反光会形成高光噪点需要用运动模糊和数据清洗把这些hard-case样本单独处理。第三模型的置信度阈值不能定得太高也不能太低。阈值定0.85漏报率高真发生事故没报警就是大事故阈值定0.6误报率高扶梯动不动急停会造成乘客恐慌。我们最后综合权衡在0.75并要求连续5帧检出才触发事件上报既压住了单帧的偶发误判又不会因为帧间连续性门槛太高而延迟响应。2.3 边缘计算单元部署边缘侧部署是整个工程里我最有体会的环节。实验室里跑GPU服务器性能当然没问题但现场设备间装不下也没必要装一台大服务器。我选型的方案是Jetson Orin Nano 8GB版整机功耗25W左右被动散热没有任何风扇噪音这在商场弱电间里非常友好。模型部署用了TensorRT推理引擎做加速FP16精度量化实测推理延迟从30毫秒降到14毫秒左右。这里要注意的是TensorRT的精度量化方案不能盲目贪低INT8量化在夜间低光照场景下精度掉点严重FP16是目前性价比最高的档位。现场跑了一个多月遇到过几次比较棘手的问题。最有代表性的是一次设备间温度异常导致Jetson降频推理延迟突然飙升到200毫秒以上整个系统的实时响应被拉垮。后面在部署配置里增加了运行状态监控每5秒上报一次推理延迟和芯片温度超过阈值自动告警。运维人员可以远程重启推理进程而不是等到设备彻底死机了才去现场处理。3. 功能安全设计与安全标准落地3.1 功能安全基础概念讲功能安全之前有必要把两个概念掰开揉碎说清楚。很多人一听功能安全以为就是“把系统做得很安全”其实这是理解偏差。功能安全的定义更严格它关注的是系统在出现故障或者外界干扰时能否维持安全状态或者合理降级而不是保证系统永远不坏。最核心的工具是风险分析。我们参考了IEC 61508电气电子可编程电子安全相关系统的功能安全和ISO/TS 25740-1电梯和自动扶梯的安全相关应用这两个标准来开展设计。具体到扶梯监控系统我们定义了两个安全目标目标一当AI系统检测到乘客摔倒或逆行等高风险行为时应在500毫秒内发出安全报警指令。目标二当AI系统自身发生故障时应在2秒内检测到故障并进入降级状态不允许输出错误的“安全”信号。这两个目标一个对实时性提出要求一个对容错性提出要求缺一不可。3.2 SIL等级与安全架构选择按照IEC 61508的要求每个安全功能都需要确定安全完整性等级SIL。SIL的判定依据是风险评估的结果主要考虑危险事件的频次、可能导致的人员伤害严重度以及能否有效规避风险。我们经过评估把这个系统需要承担的两个安全功能定在了SIL 2等级这也是工业自动化领域比较常见的目标等级对于扶梯这种设备不会强制要求SIL 3但SIL 2基本是行业惯例。SIL 2等级的安全功能对架构选择有明确要求。单通道架构原则上不推荐因为无法满足系统性的诊断覆盖率要求。我们采用了1oo2双通道架构即两个独立的处理通道同时运行相同的安全逻辑输出经过比较器表决后再联动扶梯控制器。这个架构的好处是单个通道出现故障比如传感器漂移、处理器死机、内存校验错误另一套通道依然可以独立完成安全动作不会让整个系统盲目瘫痪。同时两个通道之间的比较还能实现故障检测——如果两个通道输出不一致系统判定存在故障自动进入降级状态。代码实现层面也花了大量时间去遵守安全编码规范。我们不追求代码编写速度而是采用一套严格的防御式编程方式核心安全功能代码禁用动态内存分配禁用递归所有全局变量都有初始化值关键变量采用冗余校验保护。这些细节看上去很枯燥但正是它们构成了SIL等级可信度的基础。3.3 安全标准要求对照解析这个项目涉及的国内外标准比较多我整理了一张速查表方便大家对照了解。请注意以下标准均不涉及任何敏感内容均是以公开可查的国际和行业标准为前提标准编号标准名称与适用领域对本系统的关键设计要求IEC 61508-1至-7电气/电子/可编程电子安全相关系统的功能安全安全生命周期管理、SIL等级、风险评估、验证确认方法ISO/TS 25740-1电梯和自动扶梯的安全相关应用SRAA安全功能分类、失效率目标、报警触发条件、系统诊断范围GB 16899-2011自动扶梯和自动人行道制造与安装的安全规范设备的整体安全要求、急停装置的联动、防护措施EN 115-1:2017自动扶梯安全标准欧洲附加安全装置要求、监测装置的响应时间ISO 13849-1机械安全控制系统安全相关部件安全相关部件的性能等级PL、MTTFd、DC诊断覆盖率记忆瞬间清晰了不同标准关注的重点层次不太一样。IEC 61508是母标准解决“怎么系统性地把安全做对”的方法论问题ISO/TS 25740-1是电梯行业的具体应用导则把通用方法论转换成了电梯领域的指标体系GB和EN则侧重设备层面的物理安全措施比如扶梯本身必须有机械防护、必须有急停按钮等这些属于AI监控之外的底线保障。从验收角度来说我们项目里面有一项关键测试是“故障注入测试”即人为在AI通道或者安全控制通道中注入故障比如模拟通讯线路断路、模拟传感器信号异常观察系统故障响应是否满足安全目标。这又用到了热词里提到的“适合功能安全和故障注入的CANoe型号”CANoe是Vector公司的一款总线仿真测试工具常用于汽车领域但在扶梯安全系统通讯测试中同样适用因为它可以模拟CAN/FlexRay等总线节点向被测系统注入异常报文观察响应。电梯行业虽然常以Modbus和PROFINET为主但CANoe仍然可以模拟这些不同的总线协议只需扩展配置相应的接口卡。故障注入的结果要求每类故障都能在2秒内被系统识别并且触发安全降级动作。这个指标不是拍脑袋定的而是基于标准要求的风险可容忍区间和SIL 2安全功能的最大响应时间折算出来的。4. 现场实施与调试记录4.1 扶梯控制接口对接扶梯本身不是一个随便可以接入的外部控制系统。每台扶梯的主控器通常来自不同厂家OTIS、迅达、三菱等等对外提供的控制接口差异很大。我们在设计中选择了干接点方式继电器干接点通过通断信号传递控制指令作为对接方案这是最笨但最可靠的接口方式。无论内部协议千差万别所有扶梯主控器基本都会保留紧急停止和降速运行的干接点输入信号。这里要注意外部系统接入扶梯控制回路需要取得扶梯厂商的确认和配合尤其是涉及安全回路的改动必须符合制造商的授权要求和当地特种设备监管要求。我们采取了独立安全继电器组并联到急停回路的方式逻辑上相当于多了一个人为触发源不修改原有回路的物理拓扑从设计上规避了影响原系统安全性的问题。实际调试时遇到了一个挺头疼的问题——安全继电器复位时序。扶梯急停回路触发后系统要求必须手动复位才能重新上电运行。我们在初版逻辑中忘记接入复位信号导致AI误报触发急停后扶梯一直无法自动恢复维保人员要手动到现场复位非常不便。后面增加了远程复位权限设计仅限操作人员授权后才能远程复位同时加了故障事件记录误报原因没查清前禁止复位这个功能上线后明显减少了无效工单。4.2 算法阈值实地校准在算法落地过程中我发现一个实验室做得再好、现场依然要重新调参的普遍规律。原因在于每一台扶梯的物理特性和使用环境差异极大——坡度、梯级宽度、人流密度、光照角度都会显著影响图像特征分布。我们的调参流程分三步走。第一步基线参数复制。把实验室训练完成的模型、阈值、区域设置原样部署到示范站点连续观察3到5天收集现场真实的误报和漏报case。第二步针对性调优。对误报case密集的区域通过调整检测区域的边界来规避干扰源。举个例子商场一台扶梯的出入口刚好对着强反光地面阳光好的时段地面反光会被误识别为“摔倒后躺地”形态。我们重新画了检测区域把地面反射带剔除在外误报立刻下降到零。第三步长期监测反馈。每个场景的阈值调定后并不意味着一劳永逸。随着季节变化、照明方案调整、客流结构变化需要定期复查。我们开发了一个简单的数据报表页面每周汇总上报事件和误报率运维人员只需要每周花十分钟看一下数据就能发现异常趋势。4.3 多维度测试与验收现场验收是整个项目最紧张也最有成就感的阶段。除了常规的功能测试正常行走不报警、模拟摔倒触发急停、携带大型婴儿车触发声光报警等我们做了一系列极端场景测试。夜间低照度测试通过关闭部分区域照明模拟夜间环境验证低照度下算法检出率仍然超过95%。雨棚反光测试针对扶梯出入口有玻璃雨棚的场景专门对午后阳光直射形成的光斑进行了连续两小时压力测试。大客流遮挡测试两个人并排站在扶梯出入口时后方的摔倒行为会被前方乘客遮挡。我们验证了连续帧跟踪能够在目标重新可见后3秒内恢复状态跟踪响应延迟依然满足500毫秒发指令的指标。还有一项容易被忽略但很重要的测试就是“人误触发”测试。我们让测试人员在扶梯出入口正常站立不动只是低头看手机曲腿站立模拟出一种类似“摔倒前蹲下”的姿态。这个场景容易被模型误判为摔倒实际测试中两分钟内触发了三次误报。后来在行为分类逻辑里增加了“蹲姿保持时间超过3秒才触发报警”的规则显著改善了该场景下的误报率。5. 常见问题与排查方案速查5.1 故障现场实录这里把我在项目调试中遇到的几个典型问题整理成一张速查表方便遇到类似情况的同行快速定位。现象可能原因排查步骤解决方案算法频繁误报“摔倒”光线变化剧烈、地面反光形态相似查看误报警前后的抓拍截图确认同一时段光照变化调整检测区域、启用光照感光自适应灵敏度扶梯已触发急停但监控平台无报警消息安全信号和消息推送链路未打通或消息队列阻塞检查安全继电器组的干接点反馈状态查看MQTT服务日志添加硬触发冗余上报通道消息队列设置死信重发机制摄像头画面清晰但推理延迟突然增大边缘计算单元过热降频或后台进程占用CPU登录设备查看日志检查温度传感器读数增强散热风道限制非推理任务占用设置自动重启策略夜间几乎不报警低照度下模型检测精度掉点调阅夜间图片验证模型输出确认亮度和对比度参数调高WDR等级、开启自动白平衡、针对夜间场景单独微调多目标同时出现时只检出其一NMS非极大值抑制参数过于激进查看同帧画面检出框的数量和置信度调整目标跟踪策略启用多目标跟踪ByteTrack类算法5.2 运维避坑经验从我实际体验出发最值得强调的一条经验是不要把系统的可靠性寄托在算法准确率的“高”上而要在系统设计层面默认“算法一定会出错”来兜底。具体一点我们在事件上报平台上做了双重确认机制。AI检测到疑似异常时系统自动推送一张抓拍截图到监控人员的工作台人只需要在20秒内做一次简单确认确认后扶梯才会退出自动急停状态或者由监控人员远程触发急停。这个机制在不影响响应时间的前提下大幅减少了因AI误判导致的恐慌性急停。试运行三个月下来扶梯急停次数从初期的每周十余次下降到每月共两三次且每次急停都有明确的事件抓拍和原因分析。另外要提一下数据容灾。图像识别系统的价值依赖数据的连续性和完整性我们为每台扶梯配置了独立的存储并定期把事故相关的检测视频数据加密归档。这部分工作虽然不起眼但在事故追溯和责任界定时刻往往是关键的证据来源。画面保留时长应不少于当地相关管理规定要求的期限且必须完整记录事件前后的各若干秒连续帧。6. 标准合规性的几点个人体会关于安全标准和合规这里想分享几个从实操中总结出来的观点仅供参考。第一个体会是标准不是死的文档而是设计约束条件的集合。初接触功能安全标准时容易觉得繁复苛刻无所适从。但当你的系统真正按标准走完一遍安全生命周期从风险分析、需求定义、架构设计、软硬件实现、集成验证到运维反馈你会明显感觉到它的合理性。比如ISO/TS 25740-1里要求的失效率指标我们一开始觉得太苛刻后来拆解到具体元器件层面才发现只要设计时选型合理、冗余得当达到指标并没有想象中困难。第二个体会是与传统安全部件兼容比创新更重要。自动扶梯现有的安全系统已经非常成熟机械防护、速度监控、扶手带入口保护等都是经过大量实际考验的。AI图像识别系统切入的最佳位置是作为“额外的监控手段”而不是“替代原有安全装置”。这个定位不仅在技术上更稳妥在监管审核层面也更容易获得认可。第三个体会是现场验证的数据积累是说服力最强的安全证明。标准评审方通常不会只听你讲“我们的算法很准”而是会看你的测试报告。我们做了一套完整的场景测试矩阵包括不同光照、不同客流密度、不同扶梯型号下的检出示例和统计指标这些数据在最终验收时帮了大忙。搭好测试框架并坚持记录数据是整个项目中最值得投入的隐形资产。再提一个容易被忽视的细节系统的日常日志和事件记录是安全复审的重要依据。就算验收通过了监管机构或保险公司也可能会在后续调取检测数据。我从一开始就要求所有安全事件保留最少3个月的原始报文和过程录像事实证明这个策略相当有远见一次复盘会上正是靠这些记录排查出了某个站点的误报规律。如果你正在筹划类似的AI图像识别与功能安全结合项目最现实的路径是先选一台流量适中的扶梯做试点只跑“摔倒检测加逆行报警”这两个最核心的功能跑通整个安全控制链路后再逐步扩展。不要一上来就铺开所有算法和场景这个方向的技术演进很快先跑通闭环再逐步升级比一开始追求大而全会走得更稳。