1. PLC和IPC各守一摊的老格局卡点到底在哪1.1 PLC的看家本领和它的天花板我从2008年开始做现场调试那几年柜子里最核心的东西基本就是一台PLC加一堆继电器运气好的配个触摸屏。PLC这东西确实有过人之处梯形图从继电器逻辑演化而来电气出身的人学起来几乎零门槛输出响应在毫秒级循环周期稳定工业环境里跑个十年八年不出乱子。它最大的优势是确定性和可靠性这两点到现在依然是控制系统选型的底线。但真要把PLC当什么都能干的控制器那是在难为它。传统PLC的CPU主频普遍不高很多中端型号就几百兆赫兹内存按MB算。你要在它上面跑一个稍微像样的视觉检测结果处理、跑一个设备健康度预测模型或者做一段高速动态轨迹规划基本跑不动。更别提现在工厂越来越强调数据的流动性要求设备把运行数据主动吐给MES、ERP要支持OPC UA、Modbus TCP这些协议和云平台对话不少老旧PLC要么得外加一个通信模块要么得上位机帮忙二次转发。终端用户有时候还会提要求说我要在上位机上跑Python脚本做分析一台老PLC面对这种需求没有任何办法。1.2 IPC的开放性与它的系统性弱点于是IPC工控机顺理成章地进了柜子。IPC的优点是开放Windows或者Linux在上面跑什么软件都能装CPU和内存起步门槛高数据库、Web服务、Python、视觉SDK、高级算法库统统可以直接上。很多传统PLC搞不定的活儿IPC能轻松扛下来。但IPC也有它很难绕过去的系统性问题。第一是实时性普通Windows不是实时操作系统调度延迟受进程、驱动、杀毒软件、系统更新的影响非常大你可能明明逻辑很简单某天凌晨三点来一次自动更新重启整条产线就停了一个多小时。第二是稳定性意外断电导致系统文件损坏、硬盘故障蓝屏这些事在做项目的都应该遇到过。第三是生命周期工业设备的服役周期普遍在10到15年一台商用级IPC可能跑到第四五年就开始风扇异响、电容老化。要在生产现场长期扛着高温、粉尘、电压波动普通IPC的体质确实打折。所以很多年下来现场的常规做法是一个柜子里塞两台设备一台PLC负责逻辑控制和运动控制一台IPC负责数据采集、界面展示、通信转发和算法计算。两套系统之间还要通过网线、OPC UA或者Modbus TCP做数据交换。这个架构能干活但有明显的问题——两套设备带来了两套供电、两套接线、两套故障点工程实施和后期维护的成本都翻倍。而且两套系统之间的数据交互往往还有时延和丢包的风险监控端看到的数据跟PLC内部实际数据永远差着那么一拍。1.3 数据孤岛时代遗留的组合方案如果去梳理一下热搜词里的大部分问题——Modbus、OPC UA协议读取PLC数据、传感器、数控机床等设备运行状态数据判断设备状态、wincc与PLC仿真、倍福PLC软件运行流程——背后其实都是同一件事传统控制器在数据层的先天不足逼着大家在它周边搭建一圈补丁。这种活儿干得越多越能感觉到中间这个断层很像一条河PLC站在这边岸上算力在那边岸上你唯一的渡河工具就是加一台IPC。我打个比方。传统架构里的PLC像一个非常尽职的传统会计你让他记账、每天固定出报表他能做得一丝不苟而且从来不出错。但你让他做数据分析、预测现金流、自动跑报表他就做不到了。于是你给他配了一个实习生IPC每天把账本复印一份给他他根据这些数据再做分析。实习生聪明是聪明但复印过程有延迟有时候账本还没递到实习生就得对着旧数据做判断。更要命的是实习生隔段时间还会感冒发烧罢工你还得花心思伺候他。这说的就是当年PLC加IPC的组合核心逻辑确实稳定但数据链路复杂维护成本高难以支撑智能化需求。我以前给一个汽配厂做过改造现场是西门子S7-200 SMART控制一条半自动装配线上位机是一台普通Windows工控机跑WinCC。生产主管想做一个设备异常预判的报表每次异常、报警、停机都要在WinCC里二次导出到Excel再由车间文员整理录入。整个过程不仅耗时数据到了Excel里往往已经滞后一天对实时决策毫无帮助。这不是某一个厂的问题而是大量中小工厂普遍存在的现实。在这种背景之下边缘控制器这类的产品开始进入视野。它不是简单的PLC加电脑而是把控制逻辑、数据采集、边缘计算、协议转换甚至轻量级可视化集中在一个硬件平台里用一套编程环境统一解决。落到今天的自动化圈子里说它正在取代一部分传统IPC和PLC并不是夸张而是一个已经发生在很多项目里的趋势。2. 边缘控制器拆开看一个盒子如何同时扛下实时控制与边缘计算2.1 硬件结构不是多装了一块CPU这么简单第一次拿到边缘控制器样机时我下意识地认为它就是个加了网口的PLC或者是个加固了的IPC。真正拆开看原理图和规格说明才发现这类产品在硬件设计上做了非常关键的取舍。市面主流的边缘控制器诸如研华、倍福、汇川、东土科技等厂家的产品大多采用两种架构。第一种是单处理器加实时扩展也就是一颗较强的工业级处理器多核x86或高性能ARM在这颗芯片上同时运行一个实时操作系统和通用操作系统通过虚拟化或者硬分区技术把资源切分开。第二种是双处理器架构一颗专门做实时控制的芯片负责时钟同步、硬实时中断、EtherCAT主站这类任务另一颗负责跑Linux或者Windows做应用层计算。两种方案各有利弊单处理器成本低但实时性取决于虚拟化切分的硬隔离程度双处理器实时稳定性更强但软件协同更复杂。这里有一个很关键的点大家容易忽略边缘控制器在硬件上普遍定义了非常完整的工业接口比如多路RS485/RS232串口、双网口、CAN口、数字量输入输出、模拟量输入输出甚至还有编码器接口。这一点让它在替换传统PLC时不用额外挂一堆通信模块接线方式也和传统PLC类似。你把它当成一个装着Linux内核的PLC来用也不会觉得有什么水土不服。2.2 软件栈实时内核与通用操作系统怎么共存软件设计层面边缘控制器比传统PLC复杂得多也灵活得多。它既要保证IEC 61131-3编程环境下的实时逻辑扫描又要能跑Python、C、Node-RED这类通用开发框架还要能对外提供REST API、MQTT、OPC UA的服务端和客户端。在我用过的一款国产边缘控制器上它底层跑的是经过改造的Linux实时内核上层预装了Codesys软PLC运行时以及一个容器化的Node.js环境。梯形图逻辑依然在Codesys环境里按PLC扫描周期执行跟传统PLC没有区别但一旦有报警或者其他重要事件发生这个事件不仅能驱动PLC内部的逻辑还能通过一个事件总线实时推给上层的Python程序去做数据入库、消息发送、算法计算。两套逻辑共享同一份内存映射区数据的延迟微秒级别这在原来的PLC加IPC架构里几乎不可能做到。有人听到Linux就会问Linux会不会像Windows一样不稳定这个得看落地情况。正规工业级边缘控制器在出厂前会做电源跌落、温湿循环、震动、干扰测试整机经过这些极端条件验证跟你在淘宝随便买一个Linux工控板不是一个量级。再加上容器化的应用一旦崩溃不会拖垮实时内核极端情况下上层应用挂了底层逻辑还在跑设备至少不会处于失控状态。2.3 和传统PLC编程的最大差异软件定义和听得懂人话拿最直接的编程体验来说传统PLC的编程语言被IEC 61131-3规范框得很死梯形图、结构化文本、功能块图、顺序功能图每种语言都有自己的适用面。用梯形图写个简单的启停逻辑很舒服但要写一个复杂的设备状态判断模型、写一个基于历史数据预测刀具寿命的算法梯形图写起来会让人觉得非常痛苦。文本类的结构化文本表达能力稍好但生态还是封闭的编辑器的自动补全、在线调试功能比通用IDE差得远。边缘控制器之所以在这几年能迅速火起来一个重要的因素是它把工程人员的语言统一了。你可以在一个工程里用梯形图写底层连锁保护用C写高速数据缓存用Python写设备健康度模型用可视化组态工具直接做页面最后再把这些模块打成几个容器一键部署到设备上。调试的时候可以直接用标准IDE附加到进程加日志、打断点、远程离线分析体验跟传统PLC的梯形图在线监控完全不在一个时代。我举个例子来说明这种差异。之前我们给一个企业做过刀具磨损预测在传统方案里底层PLC只负责上传电流、振动、主轴负载这些状态真正做预测的是服务器上的一套模型服务中间还要经过OPC UA、边缘网关、数据库多跳延迟至少几百毫秒。换到边缘控制器之后PLC逻辑层直接每秒把特征值写入内存共享区Python侧每隔几秒读一次、跑一次预测如果预测结果达到换刀阈值再通过一个事先注册好的回调触发PLC内部的状态机去换刀。整个过程全部在同一台设备内完成链路短、实时性高、工程上几乎不需要做复杂的通信配置。我在做完一两次这种项目之后有一个很直观的感受以前想把设备做聪明一点点就得组一柜子的设备现在一台边缘控制器就把核算、账本、分析全干了。它没有完全抛弃PLC的确定性内核同时又给了Open系统足够的发挥空间这正是它比起传统组合方案更优雅的地方。3. 把一套PLCIPC上位机现场方案换成边缘控制器的实际操作记录3.1 案例场景一台数控机床、一台变频器、三路传感器光讲概念没意思我拿一个前两年实际做完的改造项目详细说说。那是一家做汽车零部件的工厂有一个工位原来是一台西门子S7-1200 PLC负责现场十几路数字量和一路变频器的启停另外配了一台带WinCC的IPC做参数监控。要采集的数据包括一台数控机床的实时主轴负载、三路温度传感器轴承、电机、环境、一台ABB变频器的电流和转速。原来的方案里传感器信号全部进PLC的模拟量模块变频器走Modbus RTU进PLC数控机床的负载数据则靠一台专用数据采集模块通过网口发给WinCC。整套系统维护起来相当繁琐光不同设备间的通信配置就有四五种协议。改造目标很简单用一台边缘控制器替代PLC加IPC两个设备同时保留原有的全部控制功能新增一个设备状态判断和超温报警预测功能。我选的是汇川那台AM系列边缘控制器当然选之前我测过几款最终它会胜出的原因是兼容性相对好既支持EtherCAT做主站又自带RS485和双千兆网口还能跑Codesys实时运行环境。3.2 第一步通信层的规划Modbus、OPC UA怎么接先把通信拓扑理清楚。三路温度传感器都是标准4-20mA信号这个最简单直接进边缘控制器的模拟量输入口在Codesys里面对应到AI通道不需要第三方协议。变频器是ABB ACS580支持Modbus RTU接边缘控制器的RS485口主站是边缘控制器从站地址设为3号。数控机床比较麻烦机床上只有一个小网口用FOCAS协议和外部通信但近两年它也支持OPC UA服务端了我直接用边缘控制器里的OPC UA客户端去读主轴负载、进给速度、告警代码这些数据。这一步有几个经验值得提第一地线电位问题模拟量采集最容易受干扰。我在三路传感器进线端子旁边加了一个信号隔离器并且将屏蔽层单端接地温度波动从改造前的±0.8℃缩小到了±0.2℃。第二Modbus RTU的波特率和数据格式必须先确认好ABB变频器里出厂默认是8位数据位、1位停止位、偶校验有些工程师想当然配置成无校验结果通信死活建不起来。第三OPC UA的证书和安全策略在工业现场经常被忽略有些设备出厂启用了严格的安全模式需要先在客户端导入信任证书否则握手不成功。我把OPC UA客户端直接做在边缘控制器的实时任务里轮询周期设了200毫秒。有人觉得OPC UA比较重不适合快循环其实在边缘控制器这种处理器上跑OPC UA客户端毫无压力200毫秒甚至还能再往下压。数据读上来后我直接写入内存映射区供上层Python使用整个过程不需要任何中间网关。3.3 第二步把梯形图逻辑改写成结构化文本原PLC里的控制逻辑不算复杂一个启动按钮触发变频器斜坡启动温度一到警戒值就自动停机同时把报警信息输出到柜体指示灯。我用结构化文本在Codesys里重写了一遍几百行代码搞定。梯形图和结构化文本的差异在迁移时确实存在但只要原程序里不是充满那种乱七八糟的置位复位技巧用ST重写基本没什么心理负担反而逻辑查起来更直白。不过我要专门提醒一句迁移过程中最怕的不是语言本身而是对原有程序的语义没有吃透。原PLC程序的启动条件里有某一条看起来多余的前级触点别急着删那可能是一个安全连锁。我这次迁移的时候发现原程序里有一个只有在安全门关闭时才允许变频器启停的连锁梯形图里写得很隐蔽——就是串联在主干回路末端的一个常开触点——改造时如果只看变频器使能那段代码很容易把这个连锁漏掉。我当时把整个原程序的每一个输入条件列了一个表逐条对照确认后才落成新程序。这样一个小时能完成的迁移我花了半天但这半天换来的是全套逻辑无死角的保留。在写ST代码时我还额外优化了一处把三路温度传感器的上下限和回差值做成了结构体变量可以直接在触摸屏或者Web组态界面里修改不用改程序。这在原PLC方案里也没问题只不过改了之后总要重新下载到PLC而边缘控制器上可以用OPC UA直接将变量写入运行中的设备本身就是一个优势。3.4 第三步把数据采集和API做进同一个工程改造后的设备实时数据去向要做规划一部分打在本地屏幕上即时展示一部分以JSON格式每隔5秒上传到车间MES一部分用来做机器学习预测。这三条链路如果放在以前的架构里要么在IPC上装好几个程序要么再搞一台边缘网关。现在一台边缘控制器直接扛。我在上层写了一个Python服务通过共享内存把主轴负载、三路温度、变频器电流转速全部读取出来每5秒生成一份JSON通过MQTT发到车间MES的中转服务。同时本地用内置的Web可视化工具做了一个仪表盘显示实时曲线和累计报警次数现场操作工直接浏览器就能打开不用装任何客户端。这台设备还额外开放了一个REST API让工艺工程师能远程读历史数据离线分析加工参数和刀具寿命的关系。这个过程中最有价值的体验是边缘报警规则可以直接写在Python里不用再去PLC里写一堆复杂的状态机。比如我写了一条规则如果主轴负载在当前转速档位下的期望值超过30%且持续时间超过5秒判定为刀具磨损异常这个判断会通过事件驱动PLC让设备进入一个降速运行的安全模式。以前干这种事要么要PLC工程师和上位机工程师一起协作三天要么直接拿一台服务器当边缘网关来用现在我自己一个人就能完成效率是肉眼可见的提升。3.5 第四步伺服与EtherCAT任务的改变说一个稍微进阶一点的改动。原来这个设备的上下料机构用的是传统脉冲方向控制伺服驱动器接收PLC的脉冲信号。我在这次改造里顺手把脉冲控制改成了EtherCAT总线控制用Codesys的EtherCAT主站功能直接带上伺服驱动器跑位置同步。改总线控制之后最直观的差别是接线量少了很多原来一个伺服驱动器至少要接脉冲、方向两组信号线加编码器反馈线现在一根网线串着走而且参数可以远程在线整定。位置环和速度环的参数不需要再到面板上一个一个敲了直接在Codesys里改。不过这里注意EtherCAT的同步抖动量对通信线缆的质量和布线要求很高普通超五类网线临时飞线跑了几天就出现了偶发的同步丢失报警后来换成了高柔性工业以太网电缆并按标准做了拖链布线连续运行了几个月没有再出现一次同步故障。如果你只是想把逻辑控制从传统PLC搬到边缘控制器上伺服改不改总线其实不重要但如果你的系统里有多个伺服轴并且要跑稍微复杂一点的插补运动EtherCAT配合边缘控制器的优势会非常明显。4. 我在选型部署边缘控制器时踩过的坑和验证过的结论4.1 关于实时性别被宣传的高实时忽悠了边缘控制器宣传页上会写最小循环周期可到250微秒支持EtherCAT分布式时钟同步这个指标是真实的但要看前提条件。真实项目中你不可能在一个循环周期里又跑OPC UA数据轮询又跑Python算法又去刷新上千个Modbus寄存器点还要同时伺候DB存储。任何实时系统在任务超载和资源竞争之下都会出现循环周期抖动边缘控制器也不例外。我踩过的第一个坑就是在同一台边缘控制器里既用Codesys跑500微秒的EtherCAT循环又开了一个Python进程大规模读写SQLite结果实时循环偶尔出现周期超时报警。后来把数据库写入操作迁移到独立容器并且给实时任务绑定专用CPU核心给普通应用设定CPU亲和性和优先级之后超时报警基本消失了。这提醒了我一件事边缘控制器的所谓替代不是粗暴地堆任务而是需要在操作系统层给它留出足够的隔离空间。所以我的建议是在方案前期就要对实时任务和非实时任务进行清单划分哪些环节必须用硬实时比如轴同步、安全连锁哪些环节可以容忍几十毫秒的延迟比如状态监控、数据上传、报警通知。实时任务尽量只通过网络或者共享内存通信非实时任务必须让路。这个原则在任何品牌上都适用。4.2 温度PID波动大的调节思路正好热搜词里有PLC温度PID波动温差大如何调节我在这次改造中也被温度PID折腾过一次。三路温度传感器里轴承温度是我要控制的目标是稳定在50℃±1℃。刚上线时用PID参数温差波动能达到±4℃而且有那种周期性震荡。这种现象很大程度上是因为我的采样调理时间常数跟执行机构的惯性不太匹配——加热器的热惯性大传感器响应速度快两者存在时间常数错配。解决思路分三步走。第一把PID控制周期拉长到1秒别拿控制伺服那套1毫秒周期去控温度温度系统变化本来就慢周期太长反而会加剧超调。第二给温度采样值做一个一阶低通滤波时间常数设在2秒左右滤掉电气干扰和液晶显示跳动的毛刺。第三先调比例再调积分P值从5改到2I值从60秒改到120秒最后加一个很小的微分项0.5秒这样曲线基本稳定在50℃±0.8℃。如果做完这三步温差还是大十有八九是执行机构的非线性问题——比如可控硅输出在低占空比时根本启动不了加热器这时候要在PID输出上做死区补偿或变速积分来处理。4.3 双触摸屏连接到底行不行做改造项目时现场负责人过来问能不能在一个角落加一台显示屏让另一个位置的工人也能看到设备状态和操作按钮。这个问题在热搜词里也出现了一个PLC可以接两个触摸屏吗放在传统PLC架构下答案是可以但有讲究如果两个屏只是各自作为独立HMI通过以太网与PLC通信那是常规操作但如果希望两个屏显示的画面完全同步、操作互相锁定就不是简单的双屏并联了要考虑协议、刷新周期和权限管理。边缘控制器可以用两个方案解决这类需求。第一个方案最简单——因为边缘控制器本身带Web组态页面现场任意一台电脑或平板用浏览器打开同样的IP就能看到同一个画面天然就是多屏。第二个方案是保留一个实体触摸屏通过Modbus TCP或者OPC UA与控制器通信另外一个工位就用浏览器访问。我在项目里用了第二种因为操作工还是习惯实体按键的反馈感而工艺工程师只需要在办公室看同一份数据就够了。4.4 供电、散热、安装细节边缘控制器的功耗比传统PLC高一点比一台IPC低得多。大部分型号是无风扇设计的采用铝合金外壳散热。这个设计在工业现场有利有弊无风扇意味着没有机械磨损件IP防护等级可以做高但也意味着对环境散热要求更高装在密不透风的控制柜里且旁边刚好有变频器发热源的话控制器外壳温度会非常容易到70℃以上。我在这类项目里的做法是控制柜内加装一个小型轴流风扇形成风道同时在边缘控制器的上下方各留出了至少5厘米的散热空间不要在它上面叠放其他模块。另外供电方面不要和变频器、接触器共用同一个开关电源输出回路边缘控制器最好单独一路24V直流供电并且在电源输入端加一个TVS防浪涌模块。变频器启动那一下可以把母线电压拉低好几伏供电不稳导致控制器重启的教训我见过不止一次。再有一点是关于安装导轨的。有些边缘控制器尺寸偏大标准的35mm DIN导轨虽然能卡住但如果柜内震动较强最好加一个导轨固定夹将螺纹拧到底。电机频繁起停会导致柜体长期低频振动普通卡扣式导轨夹时间长了会产生轻微位移反过来影响网口和串口连接的可靠性。4.5 程序加密与调试工具传统PLC通常都提供程序加密或者专有格式防止程序被甲方拿走被乱改。边缘控制器这类设备程序是嵌套在软件生态里的Codesys工程文件、Linux容器文件、Python代码可复制的路径比传统PLC多太多了。这意味着在项目交付时你一定得提前想好知识产权保护方案。我在交付时做了几件具体的事工程文件加密禁读将关键算法做成独立的容器镜像只在设备本地运行设备侧的SSH访问仅保留到特定维护端口并且需要密钥文件控制器的Web服务只开放HTTPS并启用账号权限分级。如果客户需要后续自行维护我能给的是运行参数级别的权限而不是整个工程的可编辑源码。5. 从趋势到落地哪些场景该马上换哪些场景还能等等5.1 AI辅助PLC代码生成与边缘控制器结合热搜词里有一个AI PLC代码生成这几年确实能看到不少用大语言模型生成PLC代码的尝试。这类工具未来对边缘控制器的影响会比传统PLC更直接原理很简单大模型生成的通常是结构化文本或功能块代码传统PLC程序往往深埋在各种专有IDE和固件体系里哪怕你生成一段ST代码导进去也会遇到型号不匹配、函数库缺失的问题。而不少边缘控制器的Codesys工程本身就是开放格式工程文件解压之后你能看到清晰的XML结构代码以标准ST/IEC形式存于其中把大模型生成的结果往里贴的兼容度要高出不少。我在内部测试中已经让模型直接生成了变频器启停、温度PID、故障停机这类ST功能块稍作修改就能编译运行整套流程半个小时以内完成。当然现在的模型还做不到直接生成一个完整的跟产线状态机耦合的项目级逻辑还需要工程人员做需求拆解和验证。但这个趋势一旦成熟边缘控制器这种开放软件栈的设备一定会是第一批吃螃蟹的人。5.2 数字孪生与边缘侧算力的匹配下一个值得关注的结合点是数字孪生。传统数字孪生方案常常把模型放在服务器端或云端设备侧只负责数据回传这就会有两个突出问题一是数据回传延迟导致模型永远在预测过去二是现场没有算力也就没法在本地快速仿真不同制造参数带来的效果。边缘控制器恰好补上了这个缺口。它本身具备高性能处理器能同时跑一个简化的设备仿真模型和真实控制逻辑这意味着你可以做实时数字孪生控制器里一边执行真实逻辑一边同步跑一个仿真模型两者结果一旦出现偏差就立刻判断物理设备出了问题。我在一个包装机械的试验台上试过这种思路用Python在边缘控制器里搭了一个产线节拍仿真模型每秒钟和实际节拍作对比如果偏差累计超过5秒站内就报警提示可能出现了隐性停机。这种能力放在老架构里不可能实现因为你根本没有足够的算力在设备本地持续跑模型。5.3 哪些场景保持传统PLC更合适虽然趋势摆在那里但我必须泼一点冷水。并不是所有项目现在都适合换边缘控制器。有一种场景我建议继续用传统PLC安全等级要求极高的功能安全回路就是那些带SIL认证、要过专业评估的紧急停车、人身保护逻辑。边缘控制器虽然也能跑安全逻辑但大多还没有取得完整的安全功能安全认证或者认证覆盖范围不如成熟的安全PLC那么全。在这种场景里最稳妥的做法是安全回路继续用确认过的安全PLC或安全继电器边缘控制器负责旁边的普通控制和数据处理。另外如果你是一个纯小型项目设备就几个按钮、几个电磁阀、一个电机没有数据上云的诉求也不需要复杂算法那我真心建议用传统的小型PLC成本低、工期短、同行都会维护。边缘控制器的价值建立在控制运算数据三者同时存在的复杂度上没有这个复杂度它有点杀鸡用牛刀。5.4 结论不是取代是边界重构把话说回标题。正在取代这四个字字面上有点刺耳但用在工程视角其实很准确不是PLC这个品类消失而是传统PLC在设备控制领域的绝对核心地位正在被边缘控制器重构。原来PLC负责所有控制、IPC负责所有计算这个边界现在已经模糊了。边缘控制器伸一只手抢了PLC的实时控制任务另一只手抢了IPC的通算和数据接入任务干得很自然。我在做完上面那个汽配厂改造之后最深的体会是用户其实不在意你的控制器是从PLC进化来的还是从IPC进化来的用户只关心三件事——设备是不是更聪明了、项目实施是不是更快了、维护是不是更省心了。边缘控制器恰好能在这三件事上给出比传统组合更好的答案所以越来越多项目选择它完全顺理成章。最后说说我自己的选择标准如果你现在正好在评估要不要在项目里用边缘控制器我给一个很朴素的标准先看控制任务的实时性要求是不是在几毫秒以内再看有没有设备状态数据需要采集或者上传最后看有没有除了逻辑控制之外的计算需求比如判断、预测、视觉、组态页面、数据库。这三个问题只要有任意两个答案是是那就值得在下一套方案里认真考虑边缘控制器。如果一个都没有继续用传统PLC不会有任何问题也不用为了追趋势而追趋势。还有一个小技巧采购前尽量让厂家提供样机把你自己的主要协议比如EtherCAT、Modbus、OPC UA直接接上去跑一周测一测循环稳定性、OPC UA连接不掉线、断电重启不丢程序。厂家宣传页上的指标只能作为参考真正适不适合你的现场拿样机实测远比看参数靠谱。边缘控制器这股风已经吹了好几年我的判断是它以后不会只是能替代IPC和PLC的定位而会慢慢演变成工厂智能化的标准现场级设备。以前你在柜子里看到PLC加电脑的组合再过几年大概率会看到一台边缘控制器就安静地装在整个控制网络的第一层往下接着传感器和伺服往上接着MES和云端。到那个时候再回头讨论取代这个词可能大家都已经忘了当初为什么要分两台设备了。