上个月去一个储能电站做联调我打开配电柜时看到一排三台设备一台小PLC负责风机联动和消防切非一台工业网关到处拉Modbus和OPC UA还有一台无风扇工控机跑着站控数据中台。三样东西来自不同品牌接线密密麻麻调试时还要三台轮流改配置。我当时就和业主说这套“PLC 网关 工控机”的老组合早就该被模块化工业控制器替换掉了。后来我确实把这一整套换成了 ARMxy 模块化工业控制器一台设备分别承担逻辑控制、协议转换和边缘数据处理。这篇内容就是这次替换的完整记录包括选型、接线、软件部署和踩坑希望能给正在做储能和自动化项目的朋友一个参考。1. 拆开看ARMxy 为什么能同时干 PLC、网关、工控机的活1.1 传统三件套的分工和被替代的本质传统自动化项目里三台设备各管一摊PLC 负责确定性控制逻辑扫描周期固定输出继电器、接触器处理急停、联锁工业网关负责跨协议转换把 PLC 或其他设备的数据翻译成 Modbus、OPC UA、MQTT 给上层工控机则跑组态软件、数据库、调度算法说白了是一个工业 Windows 或 Linux 主机。三台设备的边界很清楚但问题也很清楚——数据从 PLC 到网关再到工控机路径太长每个环节都要开发、配置、供电、接地、维护任何一个环节升级都要牵动另外两端。ARMxy 这种控制器的本质不是把三台设备塞进一个铁壳里而是把三类执行引擎放到了同一个处理器平台上。它通常采用多核 ARM 架构一部分核心跑实时控制任务另一部分核心跑 Linux 系统和边缘计算应用再通过模块化底板扩展串口、网口、CAN、数字量和模拟量通道。这样PLC 运行引擎、协议转换引擎、通用应用程序引擎都在这台设备内部通过共享内存协调而不是靠网络来回搬运。我第一次拿到 ARMxy 时也怀疑过一个 ARM 盒子能扛住实时控制吗实际用下来现代软 PLC Runtime 在实时核心上做核隔离控制周期可以做到个位数毫秒甚至亚毫秒级这对储能站控、设备自动化、过程控制的应用来说完全够用。如果你要的是高速多轴插补或者超大规模逻辑扫描那确实不是它的主战场。但它覆盖了我平时最常见的项目类型。1.2 储能和自动化场景为什么天然匹配储能项目的通信对象很杂BMS、PCS、电表、温湿度传感器、烟感、门禁、空调、消防控制器几乎都是 Modbus RTU、Modbus TCP、CAN 和干接点。传统做法里PLC 接硬线网关统一走 Modbus工控机再通过 OPC UA 或者数据库缓存去取数链路相当绕。ARMxy 的多个独立串口和网口正好对应这种“协议杂而不重”的场景一个串口挂 BMS一个串口挂 PCS一个网口连电表和 EMS数字量模块直接接消防和风机硬接线和协议采集全都在一台设备上完成。自动化项目里也是如此。车间里有不同品牌的 PLC、变频器、伺服、数控机床很多老设备只留一个 RS485 或 RS422 口协议还是厂家私有的。传统方案需要专门加一台网关去采集这些异构设备再把数据转给 MES。用 ARMxy 的话一台控制器既跑现场控制逻辑又作为 OPC UA Server 向上层系统提供统一数据模型还省掉了中间一跳。数据采集、转换、计算都发生在同一台设备里点位之间几乎不需要网络中转这对储能调度里要求数据一致性特别有帮助。2. 储能站控改造实录把机柜里的三台设备换成一台2.1 改造前的那套架构问题出在哪我接手那个储能项目时现场是典型的“老三样”架构。底层 PLC 只处理数字量逻辑但 BMS 告警需要通过串口读上来于是又引了一根线给网关网关负责轮询 PCS、BMS 和电表把寄存器映射成 JSON 通过 MQTT 发给工控机工控机收到数据后再解析把部分命令反转回 Modbus 去控制风机和照明。也就是说同样的数据在机柜里至少跑了两个来回现场联调时经常出现一个地方改了参数另外两台设备跟着出错的情况。更麻烦的是排查问题。PLC 工程师说控制命令已经发到网关了网关工程师说数据已经推送了工控机上却看不到正确状态最后查下来是一个字节序的映射差异。这种问题在传统三件套架构里非常常见因为每个设备都有自己的一套工程文件版本管理稍乱一点就非常难查。2.2 新的接线和角色划分改造时我选了一套 ARMxy 模块化控制器主控部分带双千兆网口、四路串口和两路 CAN扩展部分加了 8 路数字量输入、4 路数字量输出和一个 4 路 RS485 模块。现场接线比原来简单很多BMS、PCS、电表分别接到三路 RS485空调、烟感接到数字量输入风机和接触器接到数字量输出一个网口连交换机给 EMS另一个网口直连本地触摸屏。角色上做了明确划分控制逻辑在实时运行时中跑主要处理风机顺序启停、消防联动和信息联锁Modbus 采集任务在 Linux 侧跑轮询外部设备上的寄存器OPC UA Server 把控制变量和采集变量统一暴露给 EMS。原来需要 PLC 和网关之间做数据映射的过程现在只隔着一段共享内存。数据流变成“串口帧进内存 → 解析成变量 → OPC UA 直接读”少了好几层网络搬运。改造前后的功能分配我列成了表方便理解功能范围传统设备ARMxy 上的实现风机、接触器、消防联动等逻辑控制PLCCODESYS Runtime处理数字量模块和联锁逻辑BMS、PCS、电表等 Modbus 设备轮询工业网关Linux 侧采集程序多路 RS485 并行处理数据统一向上层系统开放网关/工控机OPC UA Server、MQTT 推送本地界面、DB、边缘算法工控机容器化 Node-RED、数据库、网页组态2.3 联调时真正让我省时间的地方原来三台设备联调基本是“先各调各的再互相磨合”。现在所有东西都在一台设备上协议解析、控制逻辑、变量命名我可以统一管理。省下来的时间主要在排查过程变量不一致的问题少了因为共享变量直接写在一个符号表里链路问题也少了因为物理上不再存在多台设备之间的网线或串口中转。实际项目里传统的站控联调我一般安排三天这次只花了一天半而且剩下的时间主要用在核对现场串口参数和 BMS 寄存器地址表。这个变化让我很确信模块化控制器不是单纯把硬件数量减少而是把系统集成阶段的复杂度也一起降下来了。3. 硬件选型的门道CPU板、IO板、通信板不能拍脑袋拼3.1 先盘信号再选板卡我自己的选型清单很多朋友一看模块化平台支持很多扩展板就容易先买一堆回来。我现在的习惯是拿一张纸先把现场所有要连接的设备列出来再标清通信方式和信号类型。比如BMS 是 RS485 还是 CANPCS 有多少个寄存器需要轮询温湿度传感器是 4-20mA 还是数字接口消防反馈是干接点还是总线这些决定 CPU 板、通信板卡和 IO 模块的搭配。CPU 性能也取决于应用负载。如果只是做几千点数据采集和简单逻辑四核 1.2GHz 级别的 ARM 平台足够如果还要在本地跑容器、数据库、复杂调度算法就选内存更大、主频更高、带硬件加密模块的型号。我的原则是控制任务和 Linux 任务最好都能有独立核心可用所以选型时优先看核心数和隔离支持。3.2 上导轨之前要注意的尺寸、端子和电源ARMxy 这类控制器多支持 DIN 导轨安装但不同扩展模块的宽度和接线端子类型可能不一样。第一次拿到套件时我最大的感受是端子方式比 PLC 更接近“接线盒”思维很多信号直接走可插拔端子所以上导轨之前最好画一张供电端子图确认 24V 电源进线、模块供电、传感器供电和输出负载供电是分开的。我习惯把输出负载电源和控制器逻辑电源隔离避免继电器动作时把控制电源拉垮。现场安装时储能柜内部往往有电池簇直流母线强电和弱电必须分隔布线。屏蔽层要单端接地Serial 信号线的 A/B 不要接反终端电阻需要按总线拓扑正确配置。这些都是老经验但在模块化控制器集成的场合特别容易被忽略因为设备看起来精简了大家会误以为不需要再关注隔离和屏蔽。3.3 数控机床、变频器等老设备串口和总线模块怎么配自动化改造里最头疼的往往是老设备。我做过一个车间采集项目现场有五台数控机床每台只有一个 RS422 接口通信协议是厂商私有的。传统方案要专门配一台协议转换网关还得每一台单独接。后来我用一块四路 RS422 串口扩展板把五台机床分别接在两个串口模块上按照各设备不同的波特率独立配置最终在 ARMxy 的 Linux 侧统一解析成 OPC UA 节点模型。实现了控制逻辑照跑数据采集也照跑一台设备解决两件事。变频器和伺服驱动器也类似。ABB、西门子、汇川这些厂家的驱动设备有的走 Modbus有的走 CANopen有的走 EtherCAT。选通信板卡时尽量选择带光电隔离的串口模块多路接口彼此独立现场电磁干扰重时会省很多事。4. 软件部署实录把软PLC、网关、工控机三个角色装进一台设备4.1 实时控制 Runtime先装好再锁定核心ARMxy 的软件部署核心有两块一块负责实时控制一块负责采集和边缘计算。实时控制我用的方案是 CODESYS Runtime先通过 Web 管理页面或 SSH 登录设备更新固件并安装运行时再用 CODESYS 工程软件连接目标 IP把包含梯形图、ST 语言和 PID 功能块的控制程序下载进去。这时设备本质上已经变成一个软 PLC普通 PLC 能写的顺启逆停、温度 PID、联锁逻辑它都能跑。有一点非常重要要把实时任务绑定到独立的核心上。我的经验是先确认 Linux 的隔离 CPU 列表再手动把控制进程绑定到这些核心。比如这样操作# 查看系统隔离了哪些 CPU 核心 cat /sys/devices/system/cpu/isolated # 找到控制运行时进程并绑定到 CPU2、CPU3 taskset -pc 2,3 $(pgrep -f codesyscontrol)这样做之后即使 Linux 侧有突发数据流量控制循环的抖动也能控制在较小范围。如果让实时任务和采集任务抢同一个核心项目后期很容易出现偶发抖动很难排查。4.2 网关和采集层Modbus、OPC UA、MQTT 一条路走通采集层我一般会用 Node-RED 或自定义 Python/Java 服务这取决于协议难度。对标准 Modbus RTU/TCP 设备Node-RED 的 Modbus 节点很直接配置好串口或网口、波特率、寄存器地址和轮询间隔数据进入内部消息队列后再映射到 OPC UA Server 地址空间或 MQTT 主题。我遇到过另一个项目要求用 Java 做采集网关因为客户已有的数据中台是 Java 技术栈。这类程序在 ARMxy 的 Linux 环境里也能直接跑起来本质上它就是一台小型工控机只是同时还能跑软 PLC。数据链路示意大概是这样Modbus 主站采集进程 → 内部共享变量 → OPC UA Server / MQTT 推送 → EMS 或 MES。整个链路不需要额外一台物理网关运维时也只盯一个系统。调试时有个细节容易踩坑OPC UA 的内置客户端和服务端之间证书信任必须提前配好。如果你同时用 OPC UA 连接自己的采集程序和上层系统不要在两处使用相同的证书别名否则连接会随机失败。4.3 工控机角色容器化部署 HMI、数据库、算法工控机原本承载的活在 ARMxy 上可以通过 Docker 容器实现。我通常在设备里跑一个轻量数据库放历史数据再跑一个 EMQX Broker负责把设备数据转发给多个下游网页型组态则直接用一个前端容器承载。容器必须设置内存和 CPU 限制否则某个异常进程可能把整个 Linux 系统拖垮。部署时我还会把采集、控制、转发拆成独立的 systemd 服务或容器重启顺序固定为数据库、消息中间件、采集程序、控制运行时。第一次做这个系统时我没有固定顺序设备断电重启后经常出现 OPC UA 客户端启动比服务端早而连不上的问题。后来写了个启动脚本问题基本绝迹。整套下来ARMxy 一台机器相当于一个高集成度的小型一体化工控机不仅省硬件还减少了一个独立的操作系统要维护。5. 算一笔降本增效的账成本、工时、功耗都别只看单价5.1 硬件采购成本对比典型配置很多人以为 ARMxy 模块化控制器的单价会很高实际算过账之后会发现和“PLC 网关 工控机”三件套相比并不贵甚至在某些挡位下更划算。项目传统配置典型ARMxy 配置典型中小型 PLC4000 - 8000 元ARMxy 套件6000 - 10000 元工业协议网关1500 - 4000 元已包含在模块化配置中无风扇工控机3000 - 7000 元已包含在 Linux 运行环境中附件、电源、导轨400 - 1000 元按需扩展模块另算合计9000 - 20000 元6500 - 11000 元当然价格会因为品牌、IO 点数、通道数量和通信接口不同而浮动。这里的关键是传统方案买的是三套系统而模块化方案经常花一份主控的钱就把另外两件的核心功能覆盖了。如果你的控制要求不高ARMxy 的价格优势更明显如果硬要和高性能 PLC 对标建议分开算性能账。5.2 项目工时省下的主要是联调和沟通成本硬件省钱只是表面真正的大头是工程实施工时。传统方案要面对三套开发环境PLC 工程师写逻辑网关工程师配置映射工控机程序员写采集和转发程序。三方还要反复联调一有 bug 就要开会定位是哪一层的责任。我在 300 点左右的储能站控项目上做过对比传统方式大致需要 12 到 15 个人天ARMxy 方案可以压到 6 到 8 个人天省下来的主要是联调和沟通成本。这套工时账对系统集成商尤其重要。同样一单项目少了中间设备的集成工作竞争力和毛利都会有非常明显的改善。很多集成商没有意识到客户愿意为“设备少、链路短、维护简单”买单这也是方案溢价的逻辑。5.3 长期功耗、空间、备件账设备数量减少后机柜空间和散热压力都小很多。传统组合的整机功耗我按 40W 估算ARMxy 按 15W 估算单台差了 25W。如果一个项目里有 100 台储能柜一年下来大概少耗电 25W × 100 × 8760 小时 ÷ 1000 21900 度电费按 0.7 元/度算约能省 1.5 万元。单柜盯着看觉得不多规模化以后就很可观。备件也比较简单。原来是三台设备各备一台钱花三份还要操心三套版本兼容性现在备件只需要一套控制器和几个常用模块。机柜里少一层安装导轨线缆也少一大截整个项目的长期维护成本自然跟着降。6. 落地的时候我踩过的五个坑和解决办法6.1 别把实时核和 Linux 核混用第一次部署 ARMxy 时我把控制逻辑和 Node-RED 采集放在同一个核心上。平时没问题但 Modbus 轮询高峰时控制任务偶尔会出现几十毫秒的抖动正好赶上继电器需要快速响应就容易产生告警。后来做了 CPU 隔离和任务绑定问题就消失了。记住模块化控制器虽然集成度高但各角色的隔离必须做扎实不能因为是一台机器就忽略资源规划。6.2 时间戳要在源头打不要在网关层二次打传统方案里网关轮询多台不同设备每个设备的采集时刻有先后但网关统一打时间戳很难保证真实时序。ARMxy 上我调整了做法采集进程从串口收完一帧数据后立刻打上本地时钟再写入共享变量控制任务读取变量时不再重置时间戳。这样上层拿到的时间轴才是真正可用的。储能项目的电池均衡和故障告警对时序很敏感这个细节直接影响运行安全性。6.3 扩展总线塞太满会把串口和网络互相踩模块化平台支持同时挂很多扩展模块但背板总线带宽有上限。我曾经一块底板上同时挂四路 RS485、两路 CAN 和多路 IO高频读写时偶尔出现某一路超时。后来把低速仪表挪到另一块独立串口模块上并把每台设备的 Modbus 轮询间隔调到 100 毫秒左右超时现象就消失了。扩展模块不是越多越好要根据实际的通信频次和背板带宽合理分布。6.4 CODESYS 运行时的授权和地址映射要提前确认软 PLC 模式下Runtime 的授权往往和设备数量、代码块大小绑定。如果你只是测试默认几个小时的试用授权没问题量产项目要做到许可证永久激活并且提前确认升级后授权不失效。我遇到过重新下载一次程序授权计数变化导致上层无法连接的情况。更要注意变量映射不要把 OPC UA 节点地址依赖自动排序否则每次升级控制程序上位机点位全部漂移现场会非常被动。6.5 固件升级不是小事先做可复现备份以前升级普通网关固件升级完发现 Modbus 映射全丢最后手动重配了两个小时。现在用 ARMxy我养成了固定习惯升级前把整个 Linux 分区配置和应用包备份用系统自带的备份工具导出升级后先验通信和控制是否正常再统一回滚风险。而且我会把部署脚本和组态工程放到 Git 仓库里这样即使机器彻底坏了也能照着仓库快速重建一台一样的设备。最后说句个人体会。做了近十年自动化项目我并不认为 ARMxy 会把传统 PLC、网关、工控机全部淘汰但在储能、设备监控、中小型自动化这类项目里它确实把三件套的痛点一次性解决了。现在我接类似项目选型时会先问自己这里需要的到底是三台设备还是一台能拆成功能域的平台如果答案是后者那模块化控制器的性价比就非常明显了。希望这篇记录能给你多一个选择。