边缘采集与网关架构专题
设备多了、协议杂了，上位机直连 PLC 的方式就扛不住了——通讯断了界面卡死、加个新设备要改整个程序、换个协议要重写通讯层。边缘网关就是来解决这个问题的： 把通讯和应用解耦，让系统分层、可扩展、可维护。本专题从认知、架构、选型、部署到工程化，把边缘采集从头到尾串起来。
一条路径走完边缘采集（六个阶段）
- 01
先建立整体认知：什么是边缘计算、为什么需要边缘网关、系统怎么分层
很多工程师做监控系统，一开始就把 PLC 通讯、数据处理、界面显示全写在一个上位机程序里。设备少了能跑，设备多了就乱：通讯断了界面卡死、加个新设备要改整个程序、换个协议要重写通讯层。边缘计算和网关架构就是来解决这个问题的——把通讯和应用解耦，让系统分层、可扩展、可维护。
- 什么是边缘计算：在靠近设备和数据源头的地方做数据采集、预处理和转发，而不是把所有原始数据都传到云端/中心服务器再处理
- 为什么需要边缘网关：① 协议转换——现场设备协议五花八门(Modbus/OPC UA/西门子S7/三菱MC)，需要统一转换成标准协议(MQTT/OPC UA)再上传；② 数据预处理——边缘端做滤波、报警判断、降采样，只传需要的数据，节省带宽；③ 断网补传——网络中断时数据本地缓存，恢复后自动补传，不丢数据；④ 减轻中心压力——边缘端承担采集和预处理，中心服务器只做存储和分析
- 系统三层架构：① 设备层——PLC、仪表、传感器等现场设备；② 边缘层——边缘网关/采集器，负责协议转换、数据采集、预处理、本地缓存；③ 应用层——SCADA/上位机、时序数据库、MES、可视化看板，负责数据存储、展示和业务逻辑
- 上位机 vs SCADA vs 边缘网关：上位机是单机版的监控界面，通常和设备直连；SCADA 是分布式监控系统，支持多站点多设备；边缘网关是专门做采集和协议转换的中间件，不做界面，只负责把数据采上来转出去。三者可以组合使用：边缘网关采集 → SCADA/上位机显示 → 时序库存储
- 02
核心架构：应用与通讯解耦、驱动工厂模式、完整数据流
边缘采集系统的核心设计思想是「解耦」：通讯层和应用层分开，采集和存储分开，协议转换和业务逻辑分开。这样每个部分都可以独立开发、独立测试、独立替换，加新设备不用改应用程序，换数据库不用改采集程序。搞清楚解耦思想和数据流，后面的选型和部署才有方向。
- 应用与通讯解耦：通讯层只负责「把设备数据读上来、转成标准格式、发出去」，应用层只负责「接收数据、处理、存储、显示」，两者通过标准协议(MQTT/OPC UA/REST API)通信。好处：加新设备只改通讯层配置，应用层不动；换应用层(比如从自研上位机换成SCADA)通讯层不动
- 驱动工厂模式：把每种协议的采集逻辑封装成独立的「驱动」(Driver)，通过统一接口调用。新增协议只需写一个新驱动，不用改主程序。配置化驱动——设备型号、寄存器地址、采集频率都写在配置文件里，不用改代码就能加新设备
- 完整数据流：设备(Modbus/OPC UA/S7/MC) → 边缘网关(协议转换+数据预处理+本地缓存) → 消息队列(MQTT Broker/Kafka，解耦采集和存储) → 时序数据库(长期存储+降采样) → 应用层(SCADA/MES/Grafana看板/报警引擎)
- 消息队列的作用：在边缘网关和数据库之间加一层 MQTT Broker(如 EMQX)或 Kafka，实现：① 削峰填谷——采集端突发大量数据时缓存在Broker，数据库慢慢消费；② 多消费者——同一份数据可以同时被时序库、报警引擎、MES消费；③ 解耦——数据库挂了不影响采集，采集端挂了不影响数据库；④ 持久化——Broker可以持久化消息，防止数据丢失
- 数据预处理：边缘端在上传前做：① 工程值转换——原始寄存器值转成实际物理量(温度、压力、流量)；② 滤波——滑动平均、中值滤波，去除毛刺；③ 报警判断——超阈值立即触发本地报警，不用等云端；④ 降采样——1秒数据降成1分钟再上传，节省带宽；⑤ 死区上传——数值变化超过阈值才上传，不变的数据不重复传
- 03
选型对比：Neuron / ThingsGateway / Node-RED / EdgeX 等边缘网关怎么选
边缘采集网关是近 5 年发展最快的工业软件品类，开源方案很多。选型不要只看支持多少协议，要结合你的团队技术栈、部署环境(ARM/x86)、设备规模、是否需要低代码配置、社区生态综合判断。这里给出主流开源边缘网关的定位和适用场景。
- Neuron（国产开源，EMQ 旗下）：C 语言开发，资源占用极低，支持 30+ 工业协议(Modbus/OPC UA/西门子S7/三菱MC/欧姆龙/AB等)，Web 界面配置，原生支持 MQTT 上报，ARM/x86 都能跑，工业场景落地多，国产替代首选
- ThingsGateway（国产开源）：.NET 6 开发，支持 Modbus/OPC UA/西门子S7/三菱MC 等协议，Web 界面配置，支持变量表达式、报警、历史存储，和 .NET 技术栈配合好，适合 C# 团队二次开发
- Node-RED（国际最流行的低代码流程引擎）：Node.js 开发，可视化拖拽编程，3000+ 节点插件，支持几乎所有工业协议和互联网服务，灵活性极高，适合快速原型和定制流程；但大规模工业采集需要自己做稳定性和性能优化
- Apache PLC4X（Apache 顶级项目）：Java 开发，统一的工业协议接入 API，支持 Modbus/OPC UA/西门子S7/三菱MC/AB/EtherNet/IP 等，适合 Java 团队做二次开发和集成，不是开箱即用的网关，而是协议接入库
- Eclipse Kura（Eclipse 基金会）：Java/OSGi 开发，面向物联网网关的完整框架，支持远程管理、容器化部署，适合需要完整网关管理平台的场景，学习曲线较陡
- Apache StreamPipes（Apache 顶级项目）：Java 开发，面向工业 IoT 的流处理平台，可视化拖拽连接数据源、处理算法和数据汇，适合需要复杂流处理和算法集成的场景
- Telegraf（InfluxData 旗下）：Go 语言开发，插件化采集器，200+ 输入插件(含 Modbus/OPC UA/SNMP)，输出到时序库，配置简单，资源占用低，适合不需要复杂协议转换、直接采集到时序库的场景
- 选型决策树：① 要开箱即用、Web配置、多协议、国产 → Neuron；② .NET 技术栈、要二次开发 → ThingsGateway；③ 要灵活定制、快速原型、连接各种服务 → Node-RED；④ Java 技术栈、要统一协议API → Apache PLC4X；⑤ 直接采集到时序库、简单配置 → Telegraf
- 04
实战部署：Neuron 部署与 Modbus 采集、Node-RED 流程开发、EMQX 消息队列
选型之后就是部署落地。以最经典的「Neuron 采集 + EMQX 转发 + TDengine 存储」组合为例，从安装部署、配置采集点、验证数据、到消息队列转发，一步步走通。这套组合是工业边缘采集最成熟的开源方案，掌握它就能应对 80% 的采集场景。
- Neuron 部署：Docker 一键部署(docker run -d --name neuron -p 7000:7000 -p 7001:7001 emqx/neuron)，或 deb/rpm 离线安装；Web 管理界面 http://IP:7000，默认账号 admin/0000，首次登录修改密码
- Neuron 配置 Modbus 采集：① 添加南向设备(Modbus TCP)，配置设备IP、端口、从站地址；② 添加点位(Group)，配置点位名称、寄存器地址、数据类型、采集频率；③ 启用设备，查看数据是否正常采集；④ 支持 Modbus RTU(串口)和 Modbus TCP，支持 01/02/03/04 功能码，支持线圈/寄存器/输入寄存器
- Neuron 配置 MQTT 上报：① 添加北向应用(MQTT)，配置 Broker 地址(EMQX)、端口、ClientID、用户名密码；② 添加订阅(Group)，选择要上报的南向设备和点位组；③ 配置上报主题(Template)，如 /neuron/{node_name}/{group_name}；④ 启用应用，在 EMQX 管理界面或 MQTT 客户端验证数据是否上报
- EMQX 部署：Docker 一键部署(docker run -d --name emqx -p 1883:1883 -p 18083:18083 emqx/emqx)，或离线安装；管理界面 http://IP:18083，默认 admin/public；配置认证(用户名密码)、ACL(主题权限)、规则引擎(数据转发到时序库/数据库/Webhook)
- Node-RED 流程开发：Docker 部署或 npm 安装；编辑器 http://IP:1880；典型流程：Modbus Read 节点(配置设备和寄存器) → Function 节点(数据处理/工程值转换) → MQTT Out 节点(上报到 EMQX)；支持 Debug 节点实时查看数据，支持 Dashboard 节点做简单监控界面
- 数据验证：① Neuron 界面查看点位实时值；② MQTTX 或 mosquitto_sub 订阅主题查看上报数据；③ EMQX 管理界面查看连接数和消息数；④ 写入时序库后用 taos 客户端查询验证；⑤ 抓包工具(Wireshark)验证 Modbus 报文是否正确
- 05
数据链路：边缘→云端同步、断网补传、多协议汇聚与边缘计算
采集跑通只是第一步，生产环境还要解决几个关键问题：网络断了数据会不会丢？多协议多设备怎么统一管理？边缘端能做哪些计算减轻中心压力？数据从边缘到云端的链路怎么设计才可靠？这是边缘采集从「能跑」到「稳定跑」的关键。
- 断网补传：边缘网关必须支持本地缓存——网络中断时数据存在本地(SQLite/文件/时序库)，网络恢复后按时间顺序自动补传。关键设计：① 缓存要有大小限制，满了覆盖最旧的(环形缓冲)；② 补传要限速，不要一恢复就把带宽占满；③ 补传要有确认机制，确保数据确实到达中心才删除本地缓存；④ Neuron 支持本地缓存，Node-RED 需要自己实现(用文件或SQLite节点)
- 边缘→云端同步架构：① 直连模式——边缘网关直接连中心时序库，适合网络稳定、点位不多的场景；② 消息队列模式——边缘→MQTT Broker(中心)→规则引擎→时序库，适合多边缘节点、需要解耦的场景；③ 分层消息队列——边缘本地 MQTT Broker → 桥接到中心 MQTT Broker → 时序库，适合边缘端也需要本地消费数据的场景；④ Kafka 模式——大规模、高吞吐场景，Kafka 做持久化和多消费者
- 多协议汇聚：一个边缘网关可以同时采集多种协议的设备——Modbus RTU(串口)、Modbus TCP(以太网)、OPC UA、西门子S7、三菱MC、欧姆龙Host Link、AB EtherNet/IP 等，统一转换成 MQTT 或 OPC UA 上报。关键：① 每个协议是独立的南向设备，互不影响；② 统一的点位命名规范(如 车间_产线_设备_点位)，方便中心端管理；③ 设备模板——同型号设备复用配置，不用逐个配置
- 边缘计算：边缘端不只是「采了就传」，还可以做：① 实时报警——超阈值立即触发本地报警(声光/继电器/短信)，不用等云端；② 数据清洗——滤波、去毛刺、异常值剔除；③ 聚合计算——分钟级/小时级聚合，只传聚合结果；④ 边缘 AI——简单的机器学习推理(如设备健康度评估、异常检测)，在边缘端实时判断；⑤ 本地闭环——边缘端直接控制设备(如温度高了自动调阀)，不依赖中心
- 边缘端资源规划：① 点位和协议数量决定 CPU 和内存；② 1000 点以内、3-5 种协议——ARM 4核2GB 足够(如树莓派4/工业网关)；③ 1000-5000 点、5-10 种协议——x86 4核4GB；④ 5000 点以上或需要边缘 AI——x86 4核8GB 以上；⑤ 存储——本地缓存建议 16GB 以上，断网 7 天的数据量估算；⑥ 网络——双网口(一个接设备网，一个接办公网/互联网)，网络隔离更安全
- 06
工程化落地：高可用、安全加固、运维监控与系统集成
从「采集跑通」到「生产环境长期稳定跑」，要回答几个工程问题：边缘网关挂了怎么办？怎么防止被攻击？怎么监控网关状态？和 SCADA/MES/ERP 怎么集成？这是一线工程师最有价值的经验部分，也是边缘采集系统落地的关键。
- 高可用：① 双机热备——关键场景部署两个边缘网关，主挂了备自动接管(VRRP/Keepalived)；② 数据不丢——本地缓存+断网补传，网关重启后数据不丢；③ 进程守护——systemd/PM2/Docker restart 自动重启崩溃的进程；④ 配置备份——网关配置定期备份，换设备快速恢复；⑤ 监控告警——网关离线、采集中断、数据异常立即告警
- 安全加固：① 网络隔离——设备网和办公网/互联网物理隔离或 VLAN 隔离，边缘网关双网口做桥接；② 最小权限——网关操作系统只开必要端口，禁用 root 远程登录，用普通用户+sudo；③ 传输加密——MQTT 用 TLS(mqtts)，OPC UA 用安全证书，Web 管理用 HTTPS；④ 认证授权——MQTT Broker 配置用户名密码和 ACL(每个设备只能发自己的主题)，网关管理界面改默认密码、加 IP 白名单；⑤ 定期更新——网关固件和操作系统定期打安全补丁；⑥ 物理安全——网关放在控制柜里，锁好，防止物理接触
- 运维监控：① 网关状态监控——在线/离线、CPU/内存/磁盘使用率、采集点数、上报频率，用 Prometheus+Grafana 或网关自带监控；② 数据质量监控——采集值是否在合理范围、是否有长时间不变的死数据、是否有异常跳变，设置告警阈值；③ 日志管理——网关日志集中收集(ELK/Loki)，方便排查问题；④ 配置管理——所有网关配置版本化管理(Git)，变更有记录，可回滚；⑤ 远程管理——Neuron/EMQX 支持远程管理和配置下发，不用跑现场
- 系统集成：① 和 SCADA 集成——SCADA 通过 OPC UA/MQTT 从边缘网关获取数据，或边缘网关把数据写入 SCADA 的数据库；② 和 MES 集成——MES 通过 REST API/OPC UA/MQTT 获取设备状态和生产数据，边缘网关做协议转换和数据清洗；③ 和 ERP 集成——生产数据(产量、能耗、设备状态)通过 MES 或直接上报 ERP；④ 和可视化集成——Grafana/自研看板从时序库查询数据做展示；⑤ 和报警系统集成——边缘端或中心端的报警通过短信/微信/邮件/声光报警器通知相关人员
- 项目落地经验：① 先做 POC——选 1-2 台设备跑通完整链路(采集→转发→存储→显示)，验证方案可行再推广；② 标准化——设备命名、点位命名、数据格式、报警级别都要标准化，方便后期管理和扩展；③ 文档——每个网关的配置、每个点位的含义、每个报警的处理流程都要有文档；④ 培训——现场运维人员要会基本的网关操作和故障排查；⑤ 渐进式——不要一次性把所有设备都接进来，分批接入，每批验证稳定后再加下一批
边学边用：现场调试在线工具
边缘采集相关软件选型（按用途分组）
边缘采集常见问题
什么是边缘计算？和云计算有什么区别？工业场景为什么需要边缘？
边缘计算(Edge Computing)是在靠近数据源头(设备、传感器)的地方做数据采集、处理和存储，而不是把所有数据都传到云端/中心服务器再处理。和云计算的核心区别：① 位置——边缘在设备旁边，云在远端数据中心；② 延迟——边缘毫秒级，云几十到几百毫秒；③ 带宽——边缘只传处理后的数据，节省带宽；④ 可靠性——边缘断网也能工作，云依赖网络；⑤ 成本——边缘硬件成本低，云按用量付费。工业场景需要边缘计算的原因：① 实时性要求高——设备控制、报警响应需要毫秒级，等云端处理来不及；② 网络不稳定——工厂车间网络经常断，全靠云会丢数据；③ 数据量大——1000 点每秒采集就是每天 8640 万条，全传云带宽和存储成本太高；④ 安全——敏感生产数据不出厂，在边缘处理更安全；⑤ 降本——边缘端做预处理和降采样，只传需要的数据，大幅降低云成本。简单说：云适合做长期存储、大数据分析和全局管理，边缘适合做实时采集、本地控制和数据预处理，两者是互补关系不是替代关系。
上位机、SCADA、边缘网关到底怎么分？各自负责什么？
这三个概念经常被混淆，其实它们定位不同、负责不同，可以组合使用：① 上位机(HMI)——单机版的监控界面，通常和一台或几台设备直连，负责数据显示、参数设置、简单报警，用 C#/WPF/WinForm 或触摸屏开发，适合小规模、单设备监控；② SCADA( Supervisory Control And Data Acquisition，数据采集与监视控制系统)——分布式监控系统，支持多站点、多设备、多用户，有实时数据库、报警管理、历史趋势、报表、用户权限等完整功能，适合中大规模工厂监控；③ 边缘网关——专门做数据采集和协议转换的中间件，不做界面，负责把各种协议的设备数据采上来、转换成标准协议(MQTT/OPC UA)、预处理后转发出去，适合多协议、多设备、需要和上层系统集成的场景。三者关系：① 小规模——上位机直连设备就够了；② 中规模——SCADA 直连设备，或 SCADA+边缘网关；③ 大规模/多协议——边缘网关采集 → SCADA/上位机显示 → 时序库存储 → MES/ERP 集成。关键区别：上位机和 SCADA 都做「显示+控制」，边缘网关只做「采集+转换」不做显示；上位机是单机版，SCADA 是分布式系统，边缘网关是中间件。实际项目中，边缘网关+SCADA+时序库是最常见的组合，边缘网关负责采集，SCADA 负责实时监控和控制，时序库负责历史数据存储和分析。
为什么要做应用与通讯解耦？直接在上位机里读 PLC 不行吗？
直接在上位机里读 PLC，设备少了(几台)能跑，但设备多了、协议多了就会遇到几个硬伤：① 耦合严重——通讯代码和业务逻辑混在一起，加个新设备要改整个程序，改通讯逻辑可能影响业务，改业务可能影响通讯；② 扩展性差——每加一种协议就要在上位机里写一套通讯代码，代码越来越乱，维护成本指数级增长；③ 稳定性差——通讯断了(比如某个设备离线)可能导致整个上位机程序卡死或崩溃，影响所有设备的监控；④ 复用性差——换个项目、换个客户，通讯代码要重写，因为和业务逻辑绑死了；⑤ 测试困难——通讯逻辑和业务逻辑混在一起，单元测试很难写，出了问题不好定位是通讯问题还是业务问题。应用与通讯解耦的好处：① 独立开发——通讯层和应用层可以并行开发，各自测试；② 独立替换——换通讯方案(比如从直连换成边缘网关)应用层不动，换应用层(比如从自研上位机换成SCADA)通讯层不动；③ 独立扩展——加新设备只改通讯层配置，应用层不用动；④ 稳定性高——通讯层出问题不影响应用层，应用层出问题不影响通讯层；⑤ 可复用——通讯层可以在多个项目中复用。解耦的实现方式：① 物理解耦——用边缘网关做通讯层，上位机/SCADA做应用层，通过标准协议(MQTT/OPC UA)通信；② 软件解耦——即使在同一个程序里，也要把通讯逻辑封装成独立的模块/类，通过接口调用，不要和业务逻辑混写。经验上，设备超过 5 台或协议超过 2 种，就应该考虑解耦；设备超过 20 台，强烈建议用边缘网关。
Neuron 和 Node-RED 怎么选？工业采集场景哪个更合适？
Neuron 和 Node-RED 都是优秀的开源边缘采集工具，但定位不同，选型取决于场景：① Neuron 是专门为工业数据采集设计的网关，开箱即用，Web 界面配置，支持 30+ 工业协议，性能高、资源占用低，适合「我要把设备数据采上来转出去」的标准采集场景；② Node-RED 是通用的低代码流程引擎，可视化拖拽编程，3000+ 节点插件，灵活性极高，适合「我要做定制化的数据处理流程、连接各种服务、快速原型验证」的场景。具体对比：① 易用性——Neuron 更简单，配置化，不需要编程；Node-RED 需要理解流程编程概念，但可视化拖拽也不难；② 协议支持——Neuron 工业协议更全(30+)，且都是工业级实现；Node-RED 靠社区节点，工业协议节点质量参差不齐，有些需要自己写；③ 性能——Neuron 是 C 语言开发，性能高、资源占用低，支持万点级采集；Node-RED 是 Node.js，性能略低，大规模采集需要优化；④ 稳定性——Neuron 是工业级产品，长期运行稳定；Node-RED 流程复杂了可能有内存泄漏或性能问题，需要自己做稳定性保障；⑤ 灵活性——Node-RED 远胜 Neuron，可以连接数据库、API、云服务、AI 模型，做复杂的数据处理和控制逻辑；Neuron 只做采集和转发，不做复杂处理；⑥ 二次开发——Neuron 支持插件开发(C语言)，但门槛高；Node-RED 可以自己写节点(JavaScript)，门槛低，社区活跃。选型建议：① 标准工业采集、多协议、大规模、要稳定——选 Neuron；② 要灵活定制、连接各种服务、快速原型、小中规模——选 Node-RED；③ 两者可以组合——Neuron 做底层采集(稳定可靠)，Node-RED 做上层数据处理和服务集成(灵活)，通过 MQTT 连接。实际项目中，Neuron 更适合生产环境的大规模采集，Node-RED 更适合原型验证和定制化流程。
边缘网关断网了怎么办？数据会丢吗？怎么保证数据完整性？
边缘网关断网是工业场景的常态(车间网络不稳定、光纤被挖断、交换机故障等)，数据不丢是边缘网关的核心能力之一。保证数据完整性的关键设计：① 本地缓存——网络中断时，采集到的数据存在本地(文件/SQLite/时序库)，不因为网络断了就丢弃；② 环形缓冲——本地缓存有大小限制，满了覆盖最旧的数据(而不是停止采集)，确保最新数据一定能存下；③ 自动补传——网络恢复后，网关按时间顺序自动把缓存的数据补传到中心，不需要人工干预；④ 补传确认——补传时要等中心确认收到后才删除本地缓存，确保数据确实到达；⑤ 补传限速——恢复后不要一下子把带宽占满，要限速补传，避免影响正常采集；⑥ 断点续传——补传过程中如果网络又断了，下次恢复后从断点继续，不要从头开始。不同工具的支持情况：① Neuron——原生支持本地缓存和断网补传，配置缓存大小和补传参数即可；② Node-RED——需要自己实现，用 file 节点或 SQLite 节点做缓存，用 function 节点做补传逻辑；③ ThingsGateway——支持本地历史存储和补传。额外保障：① 中心端也要做持久化——MQTT Broker(EMQX)支持消息持久化，即使网关补传了但数据库挂了，消息也存在 Broker 里不会丢；② 定期校验——定期比对边缘端和中心端的数据量，发现差异及时排查；③ 重要数据双写——特别重要的数据(如能耗、产量)可以同时写本地和中心，双保险。经验上，本地缓存建议至少能存 7 天的数据(按点位数和采样频率估算)，这样即使网络断一周也不会丢数据。
边缘端资源有限，能跑多少个点位？需要什么硬件配置？
边缘网关的点位容量取决于硬件配置、协议数量、采集频率和数据处理复杂度。经验估算：① 超小规模(100 点以内、1-2 种协议、1 秒采集)——树莓派4(ARM 4核2GB)或入门级工业网关就够，成本几百块；② 小规模(100-500 点、2-3 种协议、1 秒采集)——ARM 4核2GB(如 Neuron 官方推荐的工业网关)或 x86 2核4GB，稳定运行；③ 中规模(500-2000 点、3-5 种协议、1 秒采集)——x86 4核4GB，内存是关键(点位多了数据缓存占内存)；④ 大规模(2000-10000 点、5-10 种协议、1 秒采集)——x86 4核8GB 以上，建议用多个网关分担负载，不要一个网关扛所有点位；⑤ 超大规模(10000 点以上)——分层架构，多个边缘网关采集 → 汇聚网关 → 中心，每个网关负责一个车间或产线。影响点位容量的因素：① 采集频率——1 秒采集和 10 秒采集，负载差 10 倍；② 协议类型——Modbus TCP 轻量，OPC UA 较重，西门子S7/三菱MC 中等；③ 数据处理——只采集转发负载低，做滤波/报警/降采样/AI 推理负载高；④ 并发连接——同时连接的设备数多了，网络和CPU负载高；⑤ 本地缓存——缓存大了占磁盘和内存。硬件选型建议：① CPU——优先 x86(兼容性好、性能强)，ARM 适合低成本和低功耗场景；② 内存——至少 2GB，中大规模 4GB 以上；③ 存储——至少 16GB eMMC/SSD，本地缓存大的话 32GB 以上；④ 网口——至少双网口(一个接设备网，一个接办公网)，工业场景建议 4 网口；⑤ 串口——如果有 Modbus RTU 设备，需要 RS485/RS232 串口；⑥ 工业级——宽温(-40~70℃)、宽压(9~36V DC)、导轨安装、无风扇，适合车间环境。关键经验：不要让一个网关跑满，预留 30-50% 的资源余量，方便后期加点位和处理突发负载。
边缘采集网关安全吗？怎么防止被攻击？工业网络安全有哪些基本要求？
边缘网关连接着生产设备和办公网/互联网，是工业网络安全的关键节点，必须做好安全加固。工业网络安全的基本要求和实践：① 网络隔离——设备网(OT)和办公网/互联网(IT)物理隔离或 VLAN 隔离，边缘网关双网口做桥接，只开放必要的端口和协议，禁止设备直接访问互联网；② 最小权限原则——操作系统只开必要服务，禁用不必要的端口和服务；禁用 root 远程登录，用普通用户+sudo；网关管理界面改默认密码、加 IP 白名单、启用登录失败锁定；③ 传输加密——MQTT 用 TLS(mqtts://)，OPC UA 用安全证书和加密，Web 管理用 HTTPS，不要用明文传输；④ 认证授权——MQTT Broker 配置用户名密码认证，每个设备用独立账号，配置 ACL(访问控制列表)限制每个账号只能发布/订阅自己的主题，禁止匿名访问；OPC UA 配置用户名密码或证书认证；⑤ 数据安全——敏感数据(如配方、工艺参数)加密存储，定期备份，防止数据泄露；⑥ 定期更新——网关固件、操作系统、依赖库定期打安全补丁，关注 CVE 漏洞公告；⑦ 物理安全——网关放在控制柜里，锁好，防止物理接触和篡改；USB 口禁用或加锁；⑧ 监控审计——网关日志集中收集，登录和配置变更有审计记录，异常登录和操作有告警；⑨ 防火墙——网关和中心之间加防火墙，只允许必要的 IP 和端口通信；⑩ 安全评估——定期做安全扫描和渗透测试，发现漏洞及时修复。工业网络安全的核心原则：① 纵深防御——不要只靠一层防护，网络隔离、防火墙、认证、加密、监控多层防护；② 默认拒绝——默认只开必要的端口和服务，其他全关；③ 最小权限——每个用户/设备只给完成工作所需的最小权限；④ 安全左移——在设计阶段就考虑安全，不要等上线了再补；⑤ 持续运营——安全不是一次性的，要持续监控、更新、评估。对于中小企业，至少做到：网络隔离、改默认密码、传输加密、认证授权、定期更新这 5 条，就能防范 80% 的常见攻击。
继续往深走
边缘采集解决「数据怎么采上来」，数据采上来之后还要解决「怎么存、怎么查、怎么传」：