摘要： 边缘计算网关 选型最常见的误区，是把CPU、内存、接口数量直接当成项目能力。事实上，真正决定网关需求的是工作负载：设备数量、协议类型、采集事务、扫描周期、本地应用以及北向数据量共同构成系统压力。只有先建立负载模型，硬件选型才具有工程意义。
导语： 厂内数采项目刚开始时，设备数量通常不多，很多问题都不明显。等到PLC从几台扩展到几十台、变量从几百个增加到几万个，同时又接入MES、数据库和可视化系统后，原来的方案才会暴露出轮询变慢、数据延迟、CPU占用升高甚至断网恢复后集中补传等问题。选边缘计算网关 ，因此不能只验证"能不能连"，而需要验证"在计划负载下能不能长期稳定运行"。
第一步应建立南向通信负载模型。
设备数量本身并不能准确代表采集压力。两台PLC都包含1000个变量，其中一台变量地址连续，可以通过少量批量读取完成；另一台变量分散在大量不连续区域，需要产生更多通信事务。虽然变量数量相同，PLC和网关承受的通信开销却可能相差很大。
因此，选型前至少应统计四类数据：每台设备的协议类型、有效采集变量数量、单轮通信事务数量以及目标扫描周期。通过这些信息，可以粗略估算单位时间内需要处理多少请求，而不是用"最多支持多少设备"替代真正的负载评估。
第二步要把扫描周期与业务价值绑定。
设备状态、报警、能耗、产量和工艺参数并不需要采用相同采集频率。全部设置为1秒刷新虽然配置简单，却可能产生大量无效通信。
更合理的方法是给变量分级。例如与生产节拍直接相关的数据采用较短周期，累计量采用较长周期，事件类数据则重点关注状态变化。这样既能减少PLC通信压力，也能降低边缘节点和后端数据库的无效负载。
第三步要把"采集频率"和"发布频率"分开。
网关可以每秒读取一次现场数据，但MES未必需要每秒接收一次完全相同的值。南向读取服务于设备状态获取，北向发布服务于业务系统，两者应根据不同需求分别配置。
例如某状态量可以在设备侧保持快速采集，但只有发生变化时才向上发布；某些统计量则可以进行一定周期聚合后再输出。将这两个节奏解耦，是减少平台压力的重要方式。
第四步需要单独预算边缘应用资源。
当网关不仅负责采集，还需要运行数据清洗、协议服务、规则逻辑或其他本地程序时，CPU和内存需求会明显改变。
测试阶段往往只有少量设备，本地应用运行流畅；正式投产后设备数和采集频率上升，通信任务与边缘程序开始竞争资源，才出现性能问题。因此，网关选型应按照"计划最大采集负载+本地应用+北向通信同时运行"的状态进行测试，而不是只看空载资源。
第五步是网络异常与缓存策略。
"支持断网缓存"并不足以说明方案可靠。真正需要定义的是：哪些数据不能丢、允许中断多久、恢复后是否必须补传、补传数据和实时数据的优先级如何处理。
例如设备看板更关注当前状态，中间历史值部分缺失可能可以接受；质量追溯则可能要求完整时间序列。不同业务应该使用不同的数据连续性策略，而不是所有变量使用同一种缓存逻辑。
第六步是数据模型。
如果MES直接保存PLC寄存器地址，那么设备更换、程序调整后，上层系统也要同步修改。更成熟的设计，是在采集层将底层变量映射成相对稳定的业务字段，例如运行状态、生产数量、报警代码、工艺值等。
这样，PLC地址可以变化，业务字段保持不变，上层系统与设备之间的耦合显著降低。
第七步是选型后的性能验收。
工业数采项目不应该以"所有设备都能读到数据"作为最终验收标准。至少还需要验证持续运行时的扫描周期、CPU和内存占用、设备离线识别、断网恢复行为、时间戳一致性以及新增设备后的性能变化。
最好按照预计最大规模进行压力测试，并保持足够长的运行时间。短时间、少设备环境下正常，并不能证明生产环境长期稳定。
FAQ：
问题1：一台边缘计算网关到底能接多少PLC？
答：没有统一答案，应根据协议、通信事务、点位数量和扫描周期综合评估。
问题2：CPU更强是不是一定能提高PLC采集速度？
答：不一定，PLC响应速度、通信协议和采集策略也可能成为主要瓶颈。
问题3：边缘计算资源应该预留多少？
答：应根据明确的本地应用和未来设备增长预留，而不是无目的超配。
问题4：为什么一定要做压力测试？
答：因为很多性能问题只有在设备规模、通信量和边缘任务同时达到较高负载时才会暴露。
总结： 厂内数据采集系统选择边缘计算网关 ，应该从"产品参数比较"转向"工作负载建模"。通信事务、扫描周期、边缘程序、异常恢复和数据模型共同决定真实需求。把这些因素量化之后，选型才能从经验判断变成可以验证的工程决策。