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

工业自动化项目做久了你会发现一个很拧巴的现实一个中等规模的储能柜或者产线改造项目BOM 表里往往同时躺着三样东西——一台 PLC 负责逻辑控制一台协议网关负责把 Modbus、CAN、IEC 104 这些五花八门的协议翻译成上位机能懂的语言再加一台工控机跑组态、做本地 HMI 和数据缓存。三台设备三套电源三个机柜位置三份调试工时还有三份出问题时要背的锅。这两年我在储能和分布式自动化项目里反复试过一条新路子用ARMxy 这类模块化工业控制器把上面这三台设备的活儿合并到一台机器上。它不是简单地把三块板子塞进一个壳子而是从 SoC 架构层面就按控制 通信 计算一体化的思路设计的。这篇文章就把我在实际项目里踩过的坑、算过的账、调过的参数原原本本讲清楚适合正在做储能 EMS、光伏 BMU 通信、产线非标自动化以及被PLC 网关 工控机三件套折磨过的工程师参考。1. 为什么三件套架构在中小项目里越来越不划算1.1 三台设备各自的成本不只是采购价很多人算降本只盯着采购单价这是最容易踩的误区。一台主流中小型 PLC 裸机可能两三千工业网关一千出头入门工控机两三千加起来看着也就六七千。但真实项目成本远不止这些。我拿去年一个 48V/2kW 储能逆变器配套的本地控制柜举例把隐性成本摊开算成本项PLC网关工控机方案ARMxy 一体化方案硬件采购约 6500 元约 2800 元机柜空间占用3 个 DIN 位 1 个面板位1 个 DIN 位电源模块3 路独立供电 隔离1 路宽压输入接线与端子3 组电源/通信线1 组调试工时约 3 人天约 1.5 人天故障排查点3 个独立故障域1 个采购价差看起来是 3700 元但把机柜、电源、接线、调试工时全算进去单柜综合成本能差出 6000 到 8000 元。储能项目往往是批量交付一个 10 柜的项目这就是六七万的差距足够覆盖一个工程师小半年的成本。1.2 三个故障域意味着三倍的现场排查时间做过现场调试的都懂设备越多故障定位越像大海捞针。PLC 说它发出去了网关说它没收到工控机说它读到的数据是脏的——三方各执一词你在现场拿着笔记本一层层抓包一个通信不通的问题能耗掉一整天。一体化控制器最大的价值之一是把这三个故障域压缩成一个。数据从物理接口进来到协议解析到逻辑运算到本地存储和上报全在同一颗 SoC 里跑日志时间戳统一抓包和逻辑断点可以在同一个调试环境里看。我实测下来一个 Modbus 从站掉线的排查时间从原来平均 2 小时缩短到 20 分钟左右。1.3 协议碎片化才是网关存在的根本原因为什么非得有网关因为储能和自动化现场就是个协议动物园。储能逆变器爱用 Modbus RTU/TCPBMU电池管理单元常用 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 工商业储能柜项目来拆解。这个柜子的控制需求是采集 4 组电池簇的 BMU 数据电压、电流、温度、SOC、SOH走 CAN 总线。采集 2 台储能逆变器的运行数据功率、效率、故障码走 Modbus RTU。采集 1 块并网电表的电量数据走 DL/T 645 或者 Modbus。执行本地逻辑过温降功率、SOC 低限停机、消防联动。通过 MQTT 或者 IEC 104 上报给云端 EMS。本地 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(channelcan0, bustypesocketcan, bitrate500000) 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, signedTrue) * 0.1 print(f簇1 电压 {voltage}V 电流 {current}A)这里有个坑CAN 总线两端必须各接一个 120Ω 终端电阻很多现场通信不稳就是终端电阻没接或者多接了。我一般会在控制器侧预留一个可跳线的终端电阻调试时用万用表量总线电阻正常应该是 60Ω 左右两个 120Ω 并联。3.3 Modbus 采集逆变器的轮询策略逆变器走 Modbus RTURS485 半双工。多台设备挂在同一条总线上时轮询策略直接决定数据实时性。我的经验是把关键数据功率、故障状态和次要数据累计电量、温度分成两个轮询组关键组 1 秒轮一次次要组 5 到 10 秒轮一次。不要所有寄存器一股脑全读那样单次轮询时间太长故障响应会延迟。from pymodbus.client import ModbusSerialClient client ModbusSerialClient( port/dev/ttyS3, baudrate9600, parityN, stopbits1, bytesize8, timeout0.5 ) # 关键数据功率和状态 rr client.read_holding_registers(address0x1000, count10, slave1) 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 并开启datajournal模式牺牲一点性能换数据安全。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 这类模块化工业控制器本质上是把控制、通信、计算三件事从三个盒子合并到一个盒子里省的不只是钱更是现场工程师的头发。但它不是万能药选对场景、做好隔离、锁定版本、留足余量这四条做到了替换才稳。如果团队还在纯梯形图阶段不妨先从网关替代做起一步步来别一口吃成胖子。