ARMxy模块化工业控制器：替代PLC+网关+工控机三件套的降本实践

工业自动化项目做久了，你会发现一个很拧巴的现实：一个中等规模的储能柜或者产线改造项目，BOM 表里往往同时躺着三样东西——一台 PLC 负责逻辑控制，一台协议网关负责把 Modbus、CAN、IEC 104 这些五花八门的协议翻译成上位机能懂的语言，再加一台工控机跑组态、做本地 HMI 和数据缓存。三台设备，三套电源，三个机柜位置，三份调试工时，还有三份出问题时要背的锅。

这两年我在储能和分布式自动化项目里反复试过一条新路子：用ARMxy 这类模块化工业控制器，把上面这三台设备的活儿合并到一台机器上。它不是简单地把三块板子塞进一个壳子，而是从 SoC 架构层面就按"控制 + 通信 + 计算"一体化的思路设计的。这篇文章就把我在实际项目里踩过的坑、算过的账、调过的参数，原原本本讲清楚，适合正在做储能 EMS、光伏 BMU 通信、产线非标自动化，以及被"PLC + 网关 + 工控机"三件套折磨过的工程师参考。

1. 为什么"三件套"架构在中小项目里越来越不划算

1.1 三台设备各自的成本不只是采购价

很多人算降本只盯着采购单价，这是最容易踩的误区。一台主流中小型 PLC 裸机可能两三千，工业网关一千出头，入门工控机两三千，加起来看着也就六七千。但真实项目成本远不止这些。

我拿去年一个 48V/2kW 储能逆变器配套的本地控制柜举例，把隐性成本摊开算：

采购价差看起来是 3700 元，但把机柜、电源、接线、调试工时全算进去，单柜综合成本能差出 6000 到 8000 元。储能项目往往是批量交付，一个 10 柜的项目，这就是六七万的差距，足够覆盖一个工程师小半年的成本。

1.2 三个故障域意味着三倍的现场排查时间

做过现场调试的都懂，设备越多，故障定位越像大海捞针。PLC 说它发出去了，网关说它没收到，工控机说它读到的数据是脏的——三方各执一词，你在现场拿着笔记本一层层抓包，一个通信不通的问题能耗掉一整天。

一体化控制器最大的价值之一，是把这三个故障域压缩成一个。数据从物理接口进来，到协议解析，到逻辑运算，到本地存储和上报，全在同一颗 SoC 里跑，日志时间戳统一，抓包和逻辑断点可以在同一个调试环境里看。我实测下来，一个 Modbus 从站掉线的排查时间，从原来平均 2 小时缩短到 20 分钟左右。

1.3 协议碎片化才是网关存在的根本原因

为什么非得有网关？因为储能和自动化现场就是个协议动物园。储能逆变器爱用 Modbus RTU/TCP，BMU（电池管理单元）常用 CAN 或者私有串口协议，电表可能是 DL/T 645，上位机 EMS 又要求 IEC 104 或者 MQTT。传统做法是网关做协议转换，PLC 只处理干净的寄存器。

ARMxy 这类控制器的思路是：协议栈直接跑在应用层可编程的环境里。你可以在上面用 Python、C++ 或者 CODESYS 写逻辑，同时调用底层的 Modbus、CAN、MQTT 库。协议转换不再是黑盒网关的活儿，而是你代码里几行调用的事。这就把"网关"从一个硬件设备变成了一个软件模块，灵活性和可维护性完全不是一个量级。

2. ARMxy 的模块化到底"模"在哪里

2.1 核心板 + 底板 + IO 模块的三层结构

ARMxy 的模块化不是营销话术，它的物理结构确实分三层。最上面是核心板（SoC 模组），中间是带各种接口的底板，最下面是可插拔的 IO 扩展模块。这个设计的好处是，你可以根据项目需求自由组合，而不是买一台功能过剩或者不够用的整机。

核心板通常基于瑞芯微或者全志的工业级 SoC，比如 RK3568、RK3399 这类，四核 A55 或者 A72 架构，主频 1.8GHz 到 2.0GHz，配 2GB 到 4GB 内存。这个算力跑 Linux、跑 CODESYS Runtime、跑轻量级数据库和 MQTT broker 完全够用。对比传统 PLC 那点可怜的 MCU 算力，这是降维打击。

底板决定了通信接口的丰富度。常见的配置是双网口（千兆 + 百兆）、多路 RS485/RS232、CAN 口、USB、HDMI 或者 LVDS 显示接口。储能项目里，双网口可以做网络冗余或者内外网隔离，RS485 接电表和逆变器，CAN 接 BMU，一套底板全搞定。

IO 模块是真正体现"模块化"的地方。数字量输入输出、模拟量采集、继电器输出、温度采集（PT100/PT1000），都是标准化的插片式模块，坏了换一片，要加通道加一片。这比传统 PLC 换整个 CPU 或者加整个扩展机架灵活太多。

2.2 软件层面的模块化：一个 Runtime 跑多种逻辑

硬件模块化只是基础，软件模块化才是省心的关键。ARMxy 一般支持几种编程方式并存：

• CODESYS Runtime：适合习惯 IEC 61131-3 的电气工程师，梯形图、ST 语言都能用，和传统 PLC 编程体验接近。
• Python / C++ 应用：适合做协议转换、数据处理、边缘计算，库生态丰富。
• Node-RED 或类似流编排：适合快速搭数据流，做原型验证。

我实际项目里的分工是这样的：实时性要求高的逻辑（比如逆变器启停联锁、过温保护）用 CODESYS 写，扫描周期稳定在 10ms 以内；协议采集和上报用 Python 写，跑在独立的进程里，互不干扰。这种"实时逻辑 + 非实时应用"分离的架构，比把所有东西塞进一个 PLC 扫描周期要合理得多。

2.3 宽压输入与工业防护是储能场景的刚需

储能柜里的供电环境比标准控制柜恶劣。48V 电池组直接供电的场景很常见，电压波动范围可能从 36V 到 58V。ARMxy 的宽压输入一般支持 9V 到 36V 或者更宽，有些型号直接支持 48V 输入，省掉一级 DC-DC 转换。

防护等级方面，工业级产品通常做到 -40℃ 到 85℃ 工作温度，电源和通信口带隔离，ESD 防护 4kV 以上。这些参数在储能户外柜、光伏逆变器旁这种场景里不是可选项，是必选项。我见过用消费级工控机做储能本地控制的，夏天柜内温度上到 60℃ 就频繁死机，最后不得不加空调，成本反而更高。

3. 储能项目里的真实落地：从 BMU 采集到 EMS 上报

3.1 一个典型的储能本地控制链路

我拿一个实际做过的 100kWh 工商业储能柜项目来拆解。这个柜子的控制需求是：

1. 采集 4 组电池簇的 BMU 数据（电压、电流、温度、SOC、SOH），走 CAN 总线。
2. 采集 2 台储能逆变器的运行数据（功率、效率、故障码），走 Modbus RTU。
3. 采集 1 块并网电表的电量数据，走 DL/T 645 或者 Modbus。
4. 执行本地逻辑：过温降功率、SOC 低限停机、消防联动。
5. 通过 MQTT 或者 IEC 104 上报给云端 EMS。
6. 本地 HMI 显示关键数据，支持触摸操作。

传统方案是 PLC 做逻辑和 IO，网关做 CAN 转 Modbus 和协议汇聚，工控机跑组态和 MQTT。ARMxy 方案是一台控制器全包。

3.2 CAN 采集 BMU 的实操细节

BMU 通信是储能项目里最容易出问题的一环。不同厂家的 BMU 协议差异极大，有标准 CANopen 的，有自定义 J1939 扩展帧的，还有用私有串口协议的。

用 ARMxy 的 CAN 口采集，我的做法是先用candump工具把原始报文抓下来，分析 ID 和数据段规律，然后在 Python 里用python-can库解析。关键参数是波特率，储能 BMU 常用 250kbps 或者 500kbps，必须和 BMU 侧完全一致，差一点都不通。

import can bus = can.interface.Bus(channel='can0', bustype='socketcan', bitrate=500000) for msg in bus: # 假设 0x18 开头是电池簇 1 的电压电流帧 if msg.arbitration_id == 0x1801F001: voltage = int.from_bytes(msg.data[0:2], 'little') * 0.1 current = int.from_bytes(msg.data[2:4], 'little', signed=True) * 0.1 print(f"簇1 电压 {voltage}V 电流 {current}A")

这里有个坑：CAN 总线两端必须各接一个 120Ω 终端电阻，很多现场通信不稳就是终端电阻没接或者多接了。我一般会在控制器侧预留一个可跳线的终端电阻，调试时用万用表量总线电阻，正常应该是 60Ω 左右（两个 120Ω 并联）。

3.3 Modbus 采集逆变器的轮询策略

逆变器走 Modbus RTU，RS485 半双工。多台设备挂在同一条总线上时，轮询策略直接决定数据实时性。

我的经验是：把关键数据（功率、故障状态）和次要数据（累计电量、温度）分成两个轮询组，关键组 1 秒轮一次，次要组 5 到 10 秒轮一次。不要所有寄存器一股脑全读，那样单次轮询时间太长，故障响应会延迟。

from pymodbus.client import ModbusSerialClient client = ModbusSerialClient( port='/dev/ttyS3', baudrate=9600, parity='N', stopbits=1, bytesize=8, timeout=0.5 ) # 关键数据：功率和状态 rr = client.read_holding_registers(address=0x1000, count=10, slave=1) if not rr.isError(): power = rr.registers[0] * 0.1 # 假设比例因子 0.1 status = rr.registers[1]

RS485 接线要注意 A/B 线不能接反，屏蔽层单端接地。我遇到过逆变器和电表共总线时，因为波特率不同导致整条总线通信时好时坏，最后是给不同波特率的设备分了独立串口才解决。ARMxy 多路 RS485 的好处就在这里，物理隔离，互不干扰。

3.4 本地逻辑与云端上报的进程隔离

本地保护逻辑和云端上报必须解耦。我的做法是 CODESYS 跑实时逻辑，Python 跑数据采集和 MQTT 上报，两者通过共享内存或者本地 socket 交换数据。

这样设计的原因是：网络抖动或者 MQTT broker 断连时，不能影响本地保护逻辑。我见过把上报逻辑写在 PLC 主循环里的方案，网络一卡，扫描周期直接飙到几百毫秒，过温保护都迟钝了。进程隔离之后，Python 进程就算卡死重启，CODESYS 的实时逻辑照跑不误。

MQTT 上报建议开启本地缓存，网络恢复后补传。ARMxy 的 eMMC 或者 TF 卡可以存几天的历史数据，用 SQLite 或者时序数据库都行。

4. 替代工控机之后，HMI 和组态怎么办

4.1 本地 HMI 的三种实现路径

很多人担心去掉工控机之后，本地触摸屏和组态软件没地方跑。实际上有三条路：

路径一：控制器直接驱动显示屏。ARMxy 带 HDMI 或者 LVDS 接口的型号，可以直接接工业触摸屏，跑 Qt 或者 Chromium 做本地 HMI。这种方式最省设备，但界面开发需要前端或者 Qt 能力。

路径二：控制器跑 Web 服务，浏览器访问。在 ARMxy 上跑一个轻量 Web 服务（Flask、FastAPI 或者 Node.js），本地触摸屏或者平板用浏览器访问。这种方式开发快，跨平台，我比较推荐。

路径三：保留一块小触摸屏做纯显示。如果项目对本地操作要求不高，可以用支持 Modbus 或者 MQTT 的智能触摸屏，直接和控制器通信，省掉组态软件授权费。

4.2 组态软件授权的隐性成本

传统工控机方案里，组态软件授权是一笔容易被忽略的开支。一套主流组态软件的运行版授权，便宜的几千，贵的上万，而且按点数或者按设备收费。批量项目里，这笔钱乘以数量非常可观。

用 Web HMI 替代之后，前端代码是自己写的，没有按点收费的问题。虽然前期开发投入大一点，但项目复制时边际成本几乎为零。我做过一个 20 柜的项目，光组态授权就省了十几万。

4.3 数据本地存储与断网续传

工控机的一个重要作用是本地数据缓存。ARMxy 用 eMMC 或者工业级 TF 卡做存储，容量 16GB 到 64GB，存几个月的分钟级数据没问题。

存储策略上，我建议用环形缓冲或者按时段分表。SQLite 单表数据量超过百万行之后查询会变慢，可以按月分表，或者用 InfluxDB 这类时序库。断网时数据写本地，网络恢复后按时间戳补传，云端做去重。

这里有个细节：工业现场突然断电时，文件系统可能损坏。建议用带掉电保护的存储方案，或者文件系统选 ext4 并开启data=journal模式，牺牲一点性能换数据安全。

5. 选型与调试中那些文档不会写的事

5.1 算力不是越大越好，但要留余量

选 ARMxy 型号时，很多人纠结四核还是双核、2GB 还是 4GB。我的经验是：纯逻辑控制和协议采集，双核 2GB 够用；如果要跑本地 Web HMI、数据库、多个 Python 进程，直接上四核 4GB。

留余量的原因是，储能项目的需求往往会加。今天只采集 4 个簇，明天可能加到 8 个；今天只上报 MQTT，明天可能要加 IEC 104 和 Modbus TCP 双上报。算力买刚好，后期扩展就难受了。

5.2 实时性的边界要心里有数

ARMxy 跑 Linux + CODESYS，实时性比专用 PLC 的硬实时要弱一些。CODESYS 在 Linux 上一般能做到 1ms 到 10ms 的抖动，对于储能和大多数自动化场景够用，但如果你要做多轴伺服同步插补这种微秒级任务，还是得用专用运动控制器。

我的判断标准是：扫描周期要求大于 5ms 的逻辑，ARMxy 完全胜任；要求 1ms 以下的硬实时，别为难它。

5.3 隔离和接地是现场稳定的命门

工业现场 80% 的通信玄学问题，根子都在隔离和接地。ARMxy 的 RS485 和 CAN 口一般带隔离，但接线时仍要注意：

• 通信线走单独的线槽，不要和动力线捆在一起。
• 屏蔽层单端接地，接在控制器侧。
• 不同设备的地电位差大的时候，加隔离器或者用光纤转换。
• 24V 电源和 48V 电池供电要共地，否则通信参考电平会漂。

我踩过最深的坑是一个光伏项目，逆变器和控制器分别由不同电源供电，地电位差有 3V 多，Modbus 通信时通时断，查了两天才发现是共地问题。

5.4 固件和 Runtime 版本要锁定

ARMxy 这类控制器，底层是 Linux 系统，上面跑 CODESYS Runtime 或者你自己的应用。批量项目里，一定要锁定固件版本和 Runtime 版本，并且做好镜像备份。

我遇到过现场设备运行半年后，因为某次远程升级了系统库，导致 CODESYS Runtime 启动失败的情况。后来所有批量项目都先做一张"黄金镜像"，量产时统一烧录，现场不轻易升级。

6. 什么项目适合换，什么项目别硬上

6.1 适合替换的典型场景

根据我这几年实际落地的经验，下面这几类项目换 ARMxy 收益最明显：

• 工商业储能柜、户用储能一体机：协议多、批量大、对成本敏感，一体化方案优势最大。
• 光伏逆变器配套监控：需要本地逻辑 + 数据上报，算力要求中等。
• 分布式充电桩本地控制：多路 RS485 采集 + 云端上报 + 本地计费逻辑。
• 中小型非标自动化设备：IO 点数不多，但需要协议转换和联网。
• 边缘数据采集网关：本来就要跑 Linux 和 Python，顺便把控制逻辑也做了。

6.2 不建议硬上的场景

也有几类项目，我建议老老实实用传统方案：

• 安全等级要求 SIL 认证的场合：功能安全认证的 PLC 有完整的认证链条，通用控制器替代不了。
• 微秒级硬实时运动控制：多轴同步、高速插补，专用运动控制器更稳。
• 超大规模 IO 系统：几百上千点 IO 的产线，传统 PLC 的扩展性和生态更成熟。
• 团队完全没有 Linux 基础的：如果团队只会梯形图，强行上 Linux 控制器，学习和维护成本可能超过省下的硬件钱。

6.3 迁移的渐进式路径

如果拿不准，可以分步走。第一步，先用 ARMxy 替代网关，做协议转换和数据上报，PLC 和工控机不动。跑稳之后，第二步把 PLC 的逻辑迁移到 CODESYS，第三步再去掉工控机，用 Web HMI 替代组态。

这种渐进式迁移的好处是，每一步都有回退余地，风险可控。我带的几个项目都是这么过渡的，现场工程师的接受度也高。

7. 一笔真实的降本账

最后把我去年那个 100kWh 储能柜项目的实际账目摊开，给还在犹豫的人一个参考。

单柜硬件成本从 6500 降到 2800，省 3700。机柜从 3 个 DIN 位缩到 1 个，柜体尺寸小了一号，钣金和装配省约 800。电源和接线省约 400。调试工时从 3 人天降到 1.5 人天，按 800 元/人天算省 1200。组态软件授权按项目分摊，单柜省约 1500。合计单柜省约 7600 元。

这个项目一共 12 个柜子，硬件和调试直接省了 9 万多。更重要的是，现场故障率明显下降，售后出差次数从每月两三次降到一两个月一次，这部分隐性收益比硬件降本更值钱。

当然，前期投入也不能忽略。团队花了两周时间学 CODESYS 和 Python 的配合，Web HMI 开发投入了大概 10 人天。但这些投入在第二个项目就回本了，因为代码和界面可以复用。

我个人在实际操作中的体会是：ARMxy 这类模块化工业控制器，本质上是把"控制、通信、计算"三件事从三个盒子合并到一个盒子里，省的不只是钱，更是现场工程师的头发。但它不是万能药，选对场景、做好隔离、锁定版本、留足余量，这四条做到了，替换才稳。如果团队还在纯梯形图阶段，不妨先从网关替代做起，一步步来，别一口吃成胖子。