工厂断网并不等于必须停产。真正决定生产连续性的，不是网络永不中断，而是关键控制、数据采集和业务系统在通信异常时能否分层降级运行。若所有设备都依赖云端下发指令，断网会迅速放大为停机风险；合理的架构应让生产现场具备独立运行能力，让云端负责全局优化，而不是承担每一个实时控制动作。
先把控制权留在现场
“端—边—云”架构是断网自治的基础。端层连接PLC、传感器、仪表和机床，负责采集状态并执行控制；边缘层部署在车间或产线附近，承担协议转换、数据清洗、本地存储、规则判断和实时控制；云层则负责跨产线的数据汇聚、历史分析与模型训练。
断网时，边缘节点应继续执行已经配置的本地控制逻辑，例如设备状态判断、异常告警和必要的联锁动作。涉及毫秒级响应的控制闭环不能依赖云端往返，否则网络延迟或链路中断可能影响工艺稳定性。云端暂时不可用时，现场系统可以进入“自治模式”，但应限制高风险的远程配置和未经验证的策略变更。
让数据“不断档”
边缘网关需要具备本地缓存与断点续传能力。网络中断期间，原始数据和关键事件先保存在本地；通信恢复后，再按照时间顺序补传云端。这样既能保留故障前后的运行轨迹，也能避免恢复网络后集中发送数据造成新的拥塞。
数据还应分级处理：实时控制数据留在现场闭环处理，关键告警优先保存和传递，统计数据可延后上传，供云端进行趋势分析。不能把所有采样数据无差别推向云端，否则带宽压力会削弱系统在异常状态下的稳定性。
把网络故障纳入生产设计
生产网、管理网和互联网应分层隔离，关键设备、边缘节点和通信链路根据重要程度采用冗余设计。更重要的是，企业需要预先定义断网状态下的运行边界：哪些工序可以继续，哪些参数只能本地调整，何时必须人工确认，网络恢复后如何校验数据和同步状态。
断网连续生产的核心，不是简单增加网络设备，而是建立“本地可控、数据可追、恢复可校验”的机制。只有把自治逻辑、缓存策略、权限边界和恢复流程提前验证，工厂才能在通信异常时保持安全生产，并在网络恢复后平稳回到统一调度状态。
