4. Andon系统的软件架构与数据流
Andon系统在硬件层解决的是“异常怎么被触发”，而软件层解决的是“异常怎么被可靠地采集、传递、存储、分发和闭环”。如果把Andon比作工厂的神经系统，那么软件平台就是中枢：它要同时面对车间里成百上千个呼叫按钮、拉绳、PLC点位、设备报警，又要面对MES、ERP、SCADA这些上层系统，还要保证每一次呼叫都有记录、有响应、有升级、有结果。理解Andon软件架构，关键不是记住模块名称，而是看清数据从现场信号到业务闭环的完整流向。
一、Andon软件平台的基本模块
一个可落地的Andon软件平台通常由五个核心模块构成，它们各司其职又彼此依赖。
1. 采集接入模块。这是Andon与物理世界的边界。它负责对接不同来源的呼叫信号：按钮盒的干接点输入、PLC的DI/DO点位、拉绳开关、设备报警输出、扫码枪、甚至操作工在终端上的手动呼叫。采集模块需要处理电平信号、脉冲信号、Modbus/OPC UA等协议数据，并完成去抖动、边沿检测和信号有效性判断。例如一个工位按钮按下后产生一个持续200ms的低电平脉冲，采集模块要识别为一次有效呼叫，而不是多次抖动。
2. 呼叫处理与规则引擎。这是Andon的“大脑”。它接收采集模块送来的原始事件，结合工位、班次、异常类型、设备状态等上下文，判断该呼叫属于哪一类异常、应该通知谁、响应时限是多少、超时后如何升级。规则引擎通常以配置表驱动，例如“装配线A工位3的物料呼叫，通知物料员，5分钟未响应升级到班组长，10分钟未响应升级到车间主任”。
3. 消息与通知模块。负责把处理后的呼叫事件推送给正确的接收者。推送渠道包括Andon看板、工位终端、手机App、短信、企业微信/钉钉、邮件等。消息模块要保证“至少一次送达”，并记录每条通知的发送时间、接收人、送达状态和确认状态。
4. 数据存储与查询模块。负责持久化所有呼叫记录、响应记录、升级记录和关闭记录。它既要支持实时看板的高频读取，也要支持历史追溯和报表分析。通常采用关系型数据库存业务记录，用时序数据库或缓存存实时状态。
5. 接口与集成模块。负责与MES、ERP、SCADA等外部系统交换数据。它把Andon的呼叫事件、响应结果、停机时长推送给MES用于生产绩效计算，也从MES获取工单、产品、人员信息作为呼叫上下文。
二、呼叫信号采集与传输
采集与传输是Andon数据流的起点，也是最容易出问题的环节。现场信号进入Andon平台通常经过三层：现场层、边缘层、平台层。
现场层是按钮、拉绳、PLC、传感器等物理设备。边缘层是部署在车间现场的采集网关或工业PC，它通过硬接线或工业协议读取现场信号，完成协议转换和初步过滤，再通过车间以太网或工业Wi-Fi上传到平台层。平台层是Andon服务器或云平台，负责接收、解析和分发。
传输协议的选择直接影响实时性和可靠性。对于按钮、拉绳这类简单开关量，常用MQTT或HTTP上报；对于PLC点位，常用OPC UA或Modbus TCP；对于高频设备报警，可能需要消息队列如Kafka或RabbitMQ来削峰填谷。一个常见的工程做法是：边缘网关以1秒周期轮询PLC点位，检测到上升沿后立即通过MQTT发布一条JSON消息到Andon平台，消息中包含工位号、设备号、信号类型、时间戳和网关ID。
三、数据库与消息中间件
Andon平台的数据可以分成三类：实时状态数据、事件流水数据、业务结果数据。实时状态数据描述“当前哪些工位在呼叫、哪些在响应中”，变化频繁，适合放在Redis等内存数据库中，供看板毫秒级刷新。事件流水数据是每一次呼叫、响应、升级、关闭的完整记录，写入关系型数据库如MySQL或PostgreSQL，用于追溯和报表。业务结果数据是停机时长、响应时长、异常分类统计等，可由流水数据聚合生成，也可写入数据仓库供BI分析。
消息中间件在Andon中承担“解耦”和“缓冲”两个作用。采集模块不直接调用通知模块，而是把事件发布到消息队列；通知模块、存储模块、接口模块各自订阅自己关心的事件。这样即使通知服务短暂不可用，事件也不会丢失，恢复后继续消费。常用的消息中间件包括RabbitMQ、Kafka和Redis Stream。对于中小型工厂，RabbitMQ的topic exchange足以支撑按工位、按异常类型路由；对于多工厂、高并发的场景，Kafka的分区和持久化能力更合适。
四、与MES/ERP/SCADA的接口关系
Andon不是孤岛，它需要与上层系统形成数据闭环。与SCADA的关系最直接：SCADA负责设备层的实时监控，Andon从SCADA获取设备运行状态、报警代码和停机信号，同时把Andon的呼叫事件回写给SCADA，让操作员在SCADA画面上也能看到Andon状态。接口方式通常采用OPC UA或数据库中间表。
与MES的关系体现在生产执行层面。MES掌握工单、产品、工序、人员、班次信息。Andon在产生呼叫时，可以从MES查询当前工位正在加工的工单号和产品序列号，把呼叫与具体生产任务关联起来；呼叫关闭后，Andon把异常类型、响应时长、停机时长回传给MES，MES据此计算OEE、计划达成率和异常损失。接口方式常用RESTful API或消息队列。
与ERP的关系更多体现在物料和成本层面。当Andon触发物料呼叫时，可以把物料需求推送给ERP或WMS，触发补料任务；当异常导致报废或返工时，Andon可以把异常原因和数量回传ERP，用于成本归集。ERP接口通常对实时性要求较低，可以采用定时同步或批量接口。
五、一次完整呼叫的数据流示例
以某汽车零部件装配线为例，工位3的操作工发现螺栓拧紧枪扭矩异常，按下Andon按钮。数据流如下：按钮产生低电平信号，边缘网关在20ms内检测到上升沿，去抖动后生成一条JSON消息，通过MQTT发布到主题andon/call/line1/station3。Andon平台采集接入模块订阅该主题，解析消息后交给规则引擎。规则引擎根据工位3的配置，判定异常类型为“设备/工具异常”，响应责任人为维修班组，响应时限5分钟，升级时限10分钟。通知模块立即向维修班组App和Andon看板推送呼叫，同时存储模块写入一条呼叫记录，状态为“待响应”。维修人员到达现场后在终端上点击“已响应”，平台更新状态并记录响应时间。问题解决后点击“关闭”，平台记录关闭时间和处理结果，并通过接口模块把异常类型、响应时长、停机时长回传给MES。MES据此更新该工单的异常损失，并在OEE报表中体现。
这条数据流中，任何一个环节的延迟或丢失都会影响闭环效果。因此在实际部署时，需要重点监控采集网关的在线状态、消息队列的积压量、通知送达率和接口调用成功率。这些指标本身就是Andon系统健康度的体现。