无线安灯呼叫系统

| 无线安灯呼叫系统的架构

这套系统的数据走向是单向触发、双向确认的一条链：工位上的呼叫盒被人按下触发，信号通过433MHz无线传到网关，网关汇聚后用TCP/IP把结构化报文上传给服务器，服务器根据预先配置的分组和路由规则，把报警分发到车间的显示终端（看板、塔灯、音箱），同时推送给对应责任人的移动端。整个链路从触发到责任人收到通知，正常在两三秒内完成。

呼叫盒是这套架构的"神经末梢"，分散在各个工位，靠电池供电，不需要拉线。网关是"中继站"，一般装在车间高点或者信号覆盖好的位置，一个网关能管几十上百个呼叫盒。服务器是"大脑"，所有呼叫进来后在这里排逻辑、定去向、记台账。显示终端和移动端是"输出"，把报警以声光和消息的形式呈现出来，让人知道该去处理了。

这种分层架构的好处是各层各司其职，故障域隔离。网关坏了只影响它带的那些盒子，服务器可以热备，显示终端断了一个还有移动端兜底。和那种把所有逻辑塞进一个PLC的方案比，这种架构在扩展性和容错上都更从容。新增工位就是加呼叫盒配进网关，不用动服务器；换显示形式就是接新的输出终端，不用动前端。这种松耦合让系统可以跟着工厂的变化慢慢长大。

| 多工位分组呼叫逻辑

车间工位多，不可能每次呼叫都群发给所有人，那样等于没通知。分组路由解决的就是"谁该被通知"的问题。配置时把工位按区域和异常类型分组，比如A区的品质异常通知A区的质检员，B区的设备故障通知B区的维修工。呼叫盒触发时带上自己的工位编号和异常类型，服务器查表后只把通知发给对应组的责任人，其他人不受打扰。

分组的颗粒度可以按需要调。粗粒度按车间分，一个车间一个组，所有异常都发车间主管；细粒度按工段甚至单机台分，每台设备的故障只发给负责这台设备的维修工。常见做法是按工段分一级、按异常类型分二级，比如"装配二线"组下再分"品质""设备""物料"三个子组，呼叫时按工段加类型二维定位责任人。

责任人可以有主备。主责任人不在岗或者没及时响应，系统按超时规则把通知转给备选人。这种主备机制保证了即使某个人临时离开，呼叫也不会没人接。分组配置在管理后台用拖拽就能完成，不用改代码，车间调整班次或者重组产线后，运维自己几分钟就能改好路由规则。

还有一种跨组场景值得说。当某个呼叫升级到一定级别，比如设备故障15分钟没解决，系统会跨组通知到上级主管甚至生产经理，这时候就不是只发给维修工了，而是把管理链拉进来。这种升级路由是分组逻辑的延伸，让"通知"变成一个有层级的响应网络。

| 移动端报警推送方案

移动端推送让报警不再受限于车间的物理范围。维修工可能正在别处干活，质检员可能在取样，传统的看板和塔灯他们看不到，移动端把通知直接送到他们口袋里。我们提供三种通道：微信小程序、短信和APP推送，实际项目里通常两两组合用。

微信小程序是常用的通道。员工扫码关注小程序后绑定工号，服务器把报警通过小程序的订阅消息推送到微信，员工手机震一下就能看到是哪个工位、什么异常、什么时间触发的。小程序的好处是不用单独装APP，员工接受度高，消息还能在聊天列表里留痕。缺点是依赖微信的服务，偶尔会有几秒延迟，以及需要员工授权订阅消息。

短信是兜底通道。当车间WiFi或者服务器网络波动，微信推送发不出去时，系统自动转短信发送。短信走运营商通道，不依赖工厂内网，几乎不会因为局部网络问题失效。对于必须送达的关键报警，比如设备停机，短信是保险。缺点是短信有字数限制，内容比较简短，而且有几分钱的成本，所以只用在关键场景。

APP推送响应更及时，可以做到点击报警直接在APP里签到和填处理记录，闭环更顺。但APP需要员工主动安装和保持后台运行，在一些工厂推行有阻力。我们一般建议微信加短信双通道，覆盖大部分场景，对响应时效要求特别高的工位再叠加APP。三种通道不是互斥的，可以按异常类型分别配不同的推送组合。

| 快速部署的实施流程

无线方案的核心卖点就是快和省事，部署不用停产、不用开槽走线。标准流程分五步走。一是现场勘测，工程师到车间走一圈，记录工位分布、信号环境、显示终端的安装位置，同时摸清异常类型分组和责任人清单。这一步半天到一天，是后面所有配置的依据。

二是安装呼叫盒和网关。呼叫盒用魔术贴或者螺丝固定到工位，网关装在车间高点接通电源和网线。这一步纯物理安装，不碰产线设备，不影响生产，一个车间几十个盒子一两天装完。三是配置，在管理后台录工位编号、分组规则、责任人、通知通道和升级时长，这些是软配置，半天能搞定。

四是联调测试。逐个工位触发呼叫，验证看板显示、塔灯、音箱、移动端推送是否都正确送达，响应时长在不在预期内。同时模拟超时升级，看升级通知能不能正确触发到上级。测试中发现的信号死角补中继器，分组错误当场改。五是上线培训，给一线员工讲怎么触发和复位，给运维讲怎么改配置和换电池，给管理层讲怎么看数据看板。

整体周期上，中小规模车间一周内能上线，大厂房分区域分批推进也就两三周。和有线方案动辄停产几周布线比，无线在老旧车间改造上的时间优势非常明显。上线后系统稳定运行，日常维护就是定期换电池和偶尔加新工位，运维负担很轻。

| 响应时长统计与考核

安灯系统不只是"喊一嗓子"，更重要的是把"喊出去到人响应"这段时间量化出来。每次呼叫从触发到责任人签到响应，这段时间叫响应时长，系统自动记录到秒。响应时长是衡量车间异常处理效率的核心指标，也是对责任部门考核的依据。

响应时长怎么算？呼叫盒触发的瞬间记一个时间戳，责任人到场刷卡签到（或者移动端点击响应）记另一个时间戳，两个时间差就是响应时长。处理完成后复位再记一个时间戳，复位减去签到是处理时长。这两个时长分开统计，因为它们反映的是不同环节的效率——响应时长看人到得快不快，处理时长看问题解决得顺不顺。

升级规则把响应时长和管理动作绑在一起。比如设备故障，规定维修工5分钟内必须响应签到，没签到就升级通知班组长；10分钟还没响应再升级到车间主管；15分钟到生产经理。每一级的时长阈值和通知通道都可以配，不同异常类型可以设不同的阈值。这种分级升级让"没人响应"不可能悄悄发生，每拖延一段时间就有更高层级被拉进来。

KPI看板把这些数据汇总呈现。按工段、按异常类型、按责任人统计平均响应时长和处理时长，做趋势图和帕累托图，找出响应慢的工段、频次高的异常类型、处理拖后腿的责任人。这些数据每周或者每月导出报表，作为车间例会和管理考核的依据。武汉天傲科技的无线安灯呼叫系统已经在多个行业的车间落地，响应时长管理是客户实际收益明显的功能之一。如需进一步沟通，欢迎致电13007194504。