风电场的维护班组一个月要爬塔七八回，塔筒里那台升降机以前就是个直上直下的电机，什么状态都没有，人在里面一旦卡住、限位失灵或者门没关严，地面上的人完全不知情，全靠梯子爬上爬下来救。客户的安监负责人下午四点打来电话，就一个诉求:"能不能让地面看见塔里的人，出事第一时间知道"。这个诉求看起来是"加个摄像头"，实际上是一整套安全 IoT 系统的开头。
我们最后交付的定义是这样的:以视频监控、一键求助、设备状态采集、分级告警四大能力为核心，把塔筒升降机变成一台可感知、可追溯、可告警的工业设备。下面把三个子系统怎么搭、接口怎么选、权限怎么管，一条条讲清楚。
整体拆成三块，各管一段、各不越权，这个边界我是在需求评审会上按落地成本和维护难度硬划下来的。
视频监控子系统负责"看得见"。车厢内装一台摄像机和一只双向对讲，地面值班室配解码与录像，图像通过 RTSP 拉流、ONVIF 做设备控制，这样接的是市面上通用摄像头，不用被某一家私有协议锁死——我吃过私有 SDK 的亏，一旦升级就整套要换，这次全部走标准协议。
设备状态采集子系统负责"测得准"。限位开关、门磁、过载、电机电流、升降机当前位置，通过 Modbus/RS485 总线上挂的采集模块把这些数字量、模拟量收进来。RS485 在塔筒这种几十米长的走线上比别的总线稳，抗干扰也好，配 120Ω 终端电阻把反射压住。
平台服务子系统负责"管得住"和"喊得响"。设备数据上云后做曲线、台账、告警分级，并负责把告警推给对应职责的人。三块之间我用 RTU 网关做桥,边缘端先做一次本地逻辑判断，能就地处理的不用上云，只有事件和异常才往平台发。
视频这一路,我坚持 RTSP 拉流 + ONVIF 对讲。RTSP 负责把实时画面流到值班屏幕,ONVIF 负责发现设备、控制云台和配置。塔内网络环境差、带宽紧张,我把码流压到 2Mbps 以内、分辨率降到 720p,做低延迟优先,避免画面卡在关键几秒。
传感器这一路走 Modbus/RS485。每台升降机分配一个从站地址,寄存器表我按"一次冻结快照"来设计:地址 0x00 起依次是电流、位置、限位状态、门磁状态等,上位机一条读多寄存器指令就把整机状态抓完,不要一条一条读,否则 50 台设备并发起来轮询周期会拖得过长。
并发这块我按50 台设备定了性能基线,轮询周期控制在 1 秒内,告警上报做到 800ms 内送达。实测在厂务机房里接 52 台仿真从站压测,CPU 占用没超过 30%,余量是够的。
平台的账号体系我用了 RBAC,按角色分:值班员只能看实时画面和接警,维护工程师能看历史曲线和导出,管理员才能改阈值和新增设备。这个分层看起来很基本,但真上线后很管用——现场给我反馈说,以前谁都能改配置,出了岔子互相甩锅,现在权限一锁,问题范围一下收紧了。
告警分级是另一个要命的设计。我分三个级别:普通状态提醒、当机告警、人身安全告警。人身安全这一级(比如一键求助按下、门磁松开异常、长时间限位卡死)直接走最高优先级,电话+短信+站内信三重收敛,值班员 30 秒内必须点"已接警"。这一档我调了整整一个星期,把误报率从最初的一晚上七八条调到平均每天不到一条,不然大家会被假警情练出"狼来了"。
塔筒现场的网络条件比办公室差远了，风机塔往往在野外或者机房里,4G 信号一阵好一阵差。如果整套逻辑都押在云上，断网那几分钟平台就成瞎子了。所以我把"生死攸关"的判断全部下沉到边缘 RTU：车厢内的一键求助、门磁异常的本地判断、超时未到位的归位检测，这些东西在岸边 RTU 里直接判，哪怕断网，本地也能先响本地报警，网络恢复后再把这段时间的记录补传上来。云平台只做汇总和跨站管理。
补传这块我们用"断点续传+事件序号"来保证不重不漏:每个事件给一个全局递增序号,平台按序号去重,断网期间积压的数据按时间戳补传,顺序不乱。这套机制上线后经历过一次某站 4G 卡欠费断网两天,恢复后历史记录一条没丢,现场才真正放心把系统当记录依据来用。
收个尾:我做过不少工业 IoT 项目,这种安全类的最怕"好看不好用"。塔筒升降机这套做到最后,甲方看重的不是功能清单有多长,而是告警准、断网不慌、记录可追溯。这三样砸实了,系统才不是墙上的摆设。