工业现场有个很尴尬的现实控制柜里塞着PLC柜门上挂着HMI旁边再单独加一台工控机跑视觉或者数据采集三套系统各管一摊接线、供电、通信配置全是重复劳动。这几年边缘AI往产线里渗透大家第一反应往往是再加一台带显卡的盒子结果柜内空间、散热、成本又顶不住。宏集DC-Pi这类工业控制器的思路不太一样——它把PLC逻辑控制、HMI人机界面和边缘AI推理塞进同一台设备里用一套硬件跑完从实时控制到智能分析的全链路。这篇就围绕这个融合方向把它的技术逻辑、落地方式和我实际调试中踩过的坑讲透适合正在做产线智能化改造的电气工程师、自动化集成商以及想从传统PLC编程往边缘计算方向转的开发者参考。1. 为什么要把PLC、HMI和边缘AI塞进同一台控制器1.1 传统三层架构在智能化改造中的真实痛点先说说传统做法为什么越来越别扭。一条中等规模的产线典型配置是西门子或者汇川的PLC负责逻辑和运动控制威纶通或者西门子的HMI做本地操作和显示再单独配一台工控机跑上位机软件做数据记录如果要做视觉检测或者振动分析还得再加一台带独立显卡的机器。这套架构在纯逻辑控制时代没问题各司其职、互不干扰但一旦引入AI能力问题就集中爆发了。最直接的是数据链路变长。PLC采集到的传感器数据要经过现场总线到工控机工控机再通过以太网把数据送到AI推理节点推理结果又要反向传回PLC去触发动作。每一跳都有延迟每一跳都可能丢包。我做过一个简单的计数测试从PLC内部寄存器变化到AI节点收到数据中间经过Modbus TCP和一层消息队列端到端延迟稳定在80到120毫秒。对于温度、压力这类慢变量无所谓但要做高速分拣或者实时异常停机这个延迟就是致命的。其次是时钟同步问题。三台设备各自有各自的时钟PLC的扫描周期是毫秒级工控机的系统时间是另一套AI推理的时间戳又是第三套。做故障回溯的时候你很难把某个异常振动信号和PLC当时的输出状态精确对齐到同一时间轴上。我见过有项目为了对齐时间专门上了PTP精密时钟协议硬件成本和配置复杂度直接翻倍。第三是维护复杂度。三套系统意味着三套固件、三套配置、三个厂商的技术支持。现场出问题的时候电气工程师查PLCIT工程师查工控机算法工程师查模型互相扯皮。有一次客户现场HMI显示异常排查了半天发现是工控机上的数据服务挂了导致HMI读不到值但HMI本身完全正常。这种跨系统的故障定位在融合架构里根本不会出现。1.2 融合架构到底省掉了什么DC-Pi这类控制器的核心价值不是简单地把三台设备物理上拼在一起而是在软件层面打通了实时控制域和非实时计算域。它底层通常跑的是实时Linux内核PLC运行时作为内核模块或者高优先级实时任务运行保证扫描周期稳定HMI和AI推理跑在用户空间通过共享内存或者内部总线跟PLC运行时交换数据。这个设计带来的第一个好处是数据零拷贝。PLC采集的变量直接映射到共享内存区AI推理程序读这块内存就行不需要走网络协议栈。实测下来从变量更新到AI程序读到新值延迟可以压到微秒级比走Modbus TCP快了三个数量级。对于需要做实时闭环的场景比如基于振动信号的伺服参数自适应调整这个差距是决定性的。第二个好处是统一时间基准。整个控制器只有一个系统时钟PLC扫描周期、HMI刷新、AI推理时间戳全部基于同一个时钟源。做数据分析和故障回溯的时候所有数据天然对齐不需要额外做时间同步。这一点在做预测性维护的时候特别重要因为你要把振动特征、电流波形和当时的工艺参数关联起来分析时间轴错一点相关性就完全乱了。第三个好处是部署和维护简化。一个控制器一套配置工具一个IP地址。现场调试的时候电气工程师用熟悉的PLC编程环境写逻辑HMI组态在同一个工程里做AI模型通过容器或者原生程序部署。出了问题日志是统一的不用在三个系统之间来回切换。我算过一笔账一个中等规模的控制柜采用融合方案后柜内元器件数量减少约40%接线工作量减少一半以上调试周期从原来的两周压缩到五天左右。1.3 边缘AI在工业场景里到底跑什么很多人一提到工业AI就想到深度学习、大模型其实产线上真正落地的边缘AI大部分是轻量级推理任务。我梳理了一下实际项目中遇到的需求大致分四类第一类是异常检测。比如通过振动传感器判断电机轴承是否磨损通过电流波形判断刀具是否断裂。这类任务通常用传统的信号处理加简单的分类器就能做模型参数量很小但对实时性要求高必须在PLC扫描周期内出结果。第二类是质量预测。比如注塑过程中根据压力曲线预测产品是否合格焊接过程中根据电流电压判断焊点质量。这类任务需要一定的特征工程模型规模中等可以在几百毫秒内完成推理。第三类是视觉检测。比如产品表面缺陷检测、装配到位检测。这类任务计算量最大通常需要轻量级卷积神经网络推理时间在几十到几百毫秒。DC-Pi这类控制器如果带NPU或者GPU跑MobileNet级别的模型没问题但跑ResNet50以上的大模型就比较吃力了。第四类是参数优化。比如根据历史数据自动调整PID参数或者根据工况动态优化工艺窗口。这类任务不一定需要实时推理可以周期性运行对算力要求相对灵活。关键认知是边缘AI不是要把云端的大模型搬下来而是用最小的算力解决最具体的现场问题。一个只有几万参数的异常检测模型如果能把轴承故障提前三天预警它的价值就远超一个在云端跑得飞起但延迟两秒的百亿参数大模型。2. DC-Pi的硬件底子与实时性保障机制2.1 硬件配置怎么选才不浪费DC-Pi这类控制器的硬件配置跨度通常比较大从入门级的四核ARM到高配的x86加独立NPU都有。选型的时候不能只看CPU主频和核心数要结合具体任务来算。先说PLC运行时的算力需求。一个中等复杂度的逻辑控制程序扫描周期要求1毫秒的话CPU占用大概在5%到15%之间取决于程序里有多少浮点运算和通信任务。如果还要跑运动控制比如多轴插补那对实时性和算力要求就上去了建议至少留出两个物理核心专门给PLC运行时不要跟AI推理抢资源。再说AI推理的算力需求。这里有个简单的估算方法看模型的浮点运算次数FLOPs和推理频率要求。比如一个异常检测模型单次推理需要10兆FLOPs要求每100毫秒推理一次那算力需求就是100兆FLOPs每秒也就是0.1 GFLOPS。这个量级用ARM的CPU跑都绰绰有余。但如果是视觉检测一个轻量级CNN单次推理可能要500兆FLOPs要求每50毫秒一次那就是10 GFLOPS这时候就需要NPU或者GPU来加速了。我个人的选型经验是先确定PLC程序的最坏情况扫描周期再确定AI推理的最大允许延迟两者相加不能超过工艺要求的控制周期。比如工艺要求控制周期10毫秒PLC扫描占2毫秒那AI推理必须在8毫秒内完成包括数据读取、预处理、推理和后处理。如果算下来不够要么降低AI推理频率比如每5个控制周期推理一次要么换更高算力的型号。内存方面PLC运行时通常占用不大几十兆到几百兆。但AI推理如果跑视觉模型内存占用可能上G。建议至少4GB起步做视觉的话8GB以上。存储方面工业现场震动大、温度高一定要用工业级eMMC或者SSD不要用消费级存储卡我见过太多因为存储卡损坏导致系统起不来的案例。2.2 实时Linux是怎么保证PLC扫描周期稳定的DC-Pi底层跑的是打了实时补丁的Linux内核常见的是PREEMPT_RT或者Xenomai方案。这里简单说一下原理不展开太深。标准Linux内核的问题在于它为了追求吞吐量会在很多地方关中断、加锁导致高优先级任务不能及时抢占。比如一个网络中断处理程序正在跑你的PLC任务就算优先级再高也得等着。这个等待时间可能几十微秒也可能几毫秒对于要求1毫秒扫描周期的PLC来说这种抖动是不可接受的。实时补丁做的事情核心是把中断处理程序线程化并且把内核里大部分自旋锁换成可抢占的互斥锁。这样高优先级的PLC任务几乎可以在任何时刻抢占低优先级任务包括内核线程。配合CPU隔离技术把某个核心专门分配给PLC运行时连内核调度器都不去打扰它扫描周期的抖动可以控制在几十微秒以内。我实测过一组数据在四核ARM平台上不做任何优化PLC任务扫描周期抖动在正负200微秒左右做了CPU隔离和实时优先级调整后抖动降到正负20微秒以内。对于绝大多数工业控制场景这个稳定性已经足够了。但要注意实时性不是免费的。CPU隔离意味着那个核心不能跑其他任务系统整体吞吐量会下降。而且实时任务的程序要写得干净不能在PLC任务里做动态内存分配、文件IO这些可能阻塞的操作。我见过有人在PLC任务里写日志到文件结果文件系统一忙扫描周期直接飙到几十毫秒产线直接报警停机。2.3 PLC运行时与AI推理的资源隔离策略融合架构最大的风险是AI推理把PLC的CPU抢了。一个视觉模型推理突然占用大量CPU导致PLC扫描周期抖动这在产线上是不可接受的。所以资源隔离策略必须提前设计好。我的做法是物理隔离加逻辑隔离双保险。物理上用CPU隔离把PLC运行时绑定到专用核心AI推理绑定到另外的核心。逻辑上用cgroup限制AI推理进程的CPU配额和内存上限防止它失控。比如四核平台核心0和1给PLC和系统核心2和3给AI推理cgroup限制AI进程最多用150%的CPU即1.5个核心的算力留出余量应对突发。网络和IO也要隔离。PLC的现场总线通信走独立的网口或者独立的VLAN不要跟AI推理的数据上传走同一个通道。我遇到过AI推理程序往云端传大量数据把上行带宽占满导致PLC的Modbus TCP通信超时。后来把AI数据上传限速并且走独立网口问题才解决。还有一个容易被忽略的点是内存带宽。AI推理特别是视觉模型对内存带宽消耗很大。如果PLC运行时和AI推理共享内存控制器AI推理一跑起来内存带宽被占满PLC的实时性也会受影响。选型的时候要看控制器的内存架构有些高端型号会给不同核心配独立的内存通道这种就比较好。3. 从梯形图到AI模型一套工程里怎么组织三类任务3.1 PLC编程环境与AI开发环境的共存方式DC-Pi通常支持IEC 61131-3标准的编程环境常见的是CODESYS或者基于CODESYS二次开发的工具。你可以在里面用梯形图、功能块图、结构化文本写PLC逻辑跟传统PLC编程体验基本一致。同时控制器上跑的是完整的Linux系统你可以用Python、C写AI推理程序用Docker部署用标准的Linux工具做调试。这两者怎么打通核心是变量映射机制。在PLC工程里定义好需要跟AI程序交换的变量比如传感器读数、控制输出、状态标志然后在AI程序里通过共享内存或者提供的API读写这些变量。CODESYS有C语言接口可以导出变量地址AI程序直接读写这块内存。也有更高级的方案通过OPC UA或者MQTT做进程间通信但延迟会比共享内存大。我一般建议关键实时变量走共享内存非关键数据走消息队列。比如AI推理需要的振动信号走共享内存保证低延迟AI推理的结果日志、统计数据走MQTT上传不影响实时性。这里有个实操细节变量地址对齐。共享内存里的变量要按自然边界对齐比如32位浮点数要放在4字节对齐的地址上否则某些ARM平台会触发对齐异常程序直接崩。我在CODESYS里导出变量表的时候会手动检查一遍地址确保没有跨边界的情况。3.2 用AI辅助生成PLC代码的边界在哪里现在AI编程助手很火很多人问能不能用AI直接生成PLC梯形图或者结构化文本。我的实测结论是辅助可以替代不行。AI在PLC编程里能帮上忙的地方主要有几个。一是生成重复性逻辑比如几十个电机的启停控制、报警处理你把模式描述清楚AI能快速生成框架代码你再去填具体地址和参数。二是解释现有代码拿到一段别人写的复杂梯形图让AI帮你分析逻辑比自己一行行看快很多。三是生成注释和文档这个确实省时间。但AI生成的PLC代码有几个硬伤。第一是安全逻辑不可靠。急停、安全门、互锁这些逻辑AI生成的代码可能看起来对但边界条件处理不严谨。我测试过让AI生成一个星三角降压启动的逻辑它把切换延时写成了固定值没有考虑电机功率和负载惯量的影响实际用的时候切换瞬间电流冲击很大。第二是不熟悉具体硬件。不同品牌的PLC甚至同一品牌不同型号指令集和特殊功能块都不一样。AI可能给你生成一个在西门子PLC上能跑的代码但你的硬件是汇川指令根本不兼容。第三是调试困难。AI生成的代码如果出了问题你如果不完全理解它的逻辑排查起来比自己写的还费劲。我的建议是把AI当成一个打字快的实习生它出的东西你必须逐行审查安全相关的逻辑必须自己写。用AI生成框架自己填核心逻辑这样效率和质量都能兼顾。3.3 HMI组态与AI结果的可视化呈现HMI在融合架构里的角色也在变化。传统HMI就是显示PLC变量、做按钮操作现在还要展示AI推理的结果比如异常评分、预测剩余寿命、质量分类结果。DC-Pi上的HMI通常有两种实现方式。一种是本地HMI直接在控制器上跑Web-based的HMI通过浏览器或者触摸屏访问。这种方式的好处是部署简单不需要额外的HMI硬件而且可以远程访问。另一种是传统HMI软件通过以太网跟控制器通信这种方式适合已经有HMI硬件、不想换的场景。我比较推荐Web-based HMI特别是做AI可视化的时候。因为Web技术栈灵活可以用ECharts画趋势图用Three.js做3D可视化展示AI推理的置信度、特征重要性这些传统HMI很难做的东西。而且Web HMI天然支持远程访问工程师在办公室就能看到现场画面。但Web HMI也有坑。实时性不如传统HMI浏览器渲染有延迟做高频刷新的时候会卡。我的做法是关键控制按钮和状态显示用传统HMI或者本地原生界面AI分析结果、趋势图、报表这些用Web HMI两者互补。还有一个细节是AI结果的可解释性展示。产线操作工不关心模型的F1分数他们只想知道这个产品有没有问题这台设备要不要停机。所以HMI上展示AI结果的时候要转化成操作工能理解的语言。比如不要显示异常评分0.87而是显示轴承磨损风险高建议24小时内检查。这个转化逻辑要在AI程序里做好HMI只负责展示。4. 边缘AI模型在工业控制器上的部署实操4.1 模型选型不是越大越好工业边缘AI的模型选型核心原则是够用就好。我见过太多项目算法团队在服务器上训了一个ResNet50准确率95%然后想往边缘控制器上部署发现推理一次要500毫秒根本满足不了产线节拍。正确的做法是从任务需求反推模型复杂度。先明确几个指标推理延迟上限、准确率下限、可用的算力资源。然后在这个约束下选模型。对于异常检测类任务我通常先用传统方法做基线。比如振动信号先做FFT提取特征频率的幅值然后用一个简单的阈值或者逻辑回归分类。如果这个基线能达到90%的准确率那就没必要上深度学习。实际上很多工业异常检测任务传统信号处理方法加简单分类器就能做到95%以上而且推理时间在微秒级。如果传统方法不够再考虑轻量级神经网络。比如一维卷积网络1D-CNN处理振动或电流信号参数量可以控制在几万到几十万推理时间在毫秒级。视觉任务可以用MobileNetV3、ShuffleNet这些轻量级骨干网络输入分辨率降到224x224甚至128x128推理时间可以压到几十毫秒。模型量化是另一个关键手段。把FP32的模型量化成INT8模型大小减少75%推理速度提升2到4倍准确率损失通常在1%以内。DC-Pi如果带NPU通常对INT8有专门加速量化后的模型跑起来飞快。但要注意量化需要校准数据集校准数据要能代表现场的实际数据分布否则量化后准确率可能掉得厉害。4.2 从训练到部署的完整链路一个完整的边缘AI部署链路大致分五步数据采集、模型训练、模型转换、部署上线、监控迭代。数据采集是最容易被低估的一步。很多项目失败不是因为模型不好而是训练数据跟现场数据分布不一致。我的做法是在产线上先跑一段时间的纯数据采集把各种工况下的数据都采到包括正常工况、异常工况、启停过程、不同班次。数据量不用太大但覆盖面要全。标注的时候要跟工艺工程师一起做确保标签准确。模型训练通常在服务器或者云端做用PyTorch或者TensorFlow。训练的时候要注意输入数据的预处理方式必须跟部署时一致。我见过一个项目训练时用了标准化部署时忘了做结果模型输出完全不对。建议把预处理逻辑也封装成模型的一部分或者用ONNX把预处理和后处理都包含进去。模型转换是把训练框架的模型转成控制器能跑的格式。常见的是转ONNX然后再转成控制器NPU支持的格式比如RKNN、TensorRT或者OpenVINO。转换过程中要验证精度确保转换前后模型的输出差异在可接受范围内。部署上线就是把转换后的模型文件放到控制器上写一个推理程序加载模型、读共享内存、做推理、写结果。这个程序可以用Python写也可以用C写。Python开发快但启动慢、内存占用大C性能好但开发周期长。我一般先用Python做原型验证跑通了再用C重写关键部分。监控迭代是持续的过程。模型上线后要监控推理延迟、准确率、数据分布漂移。如果发现准确率下降要分析是数据分布变了还是模型老化了然后决定是重新训练还是调整阈值。4.3 推理程序的性能优化技巧推理程序跑在控制器上资源有限优化很重要。我总结几个实用的技巧。批处理。如果推理频率不高比如每秒几次可以把多次推理攒成一批一起做提高NPU或者GPU的利用率。但批处理会增加延迟要权衡。对于实时性要求高的任务批大小为1就行。内存复用。推理程序里不要频繁申请释放内存提前分配好输入输出缓冲区循环使用。Python里可以用numpy的预分配数组C里用内存池。我见过一个Python推理程序每次推理都新建一个numpy数组跑几个小时就内存碎片化性能下降一半。线程绑定。把推理线程绑定到固定的CPU核心避免频繁切换核心导致缓存失效。如果控制器有NPU推理线程要跟NPU驱动配合好避免阻塞。模型剪枝。如果模型还是太大可以做结构化剪枝去掉不重要的通道或者层。剪枝后要重新微调恢复准确率。剪枝加量化组合使用模型可以压缩到原来的十分之一。输入分辨率调整。视觉模型对输入分辨率很敏感降低分辨率能大幅减少计算量。但分辨率太低会影响小目标检测。我的经验是先确定能接受的最低分辨率然后在这个分辨率下优化模型结构。5. 现场调试中那些文档不会写的事5.1 电磁干扰对AI推理的隐形影响工业现场的电磁环境比实验室恶劣得多。变频器、伺服驱动器、接触器动作都会产生强烈的电磁干扰。这些干扰不仅影响模拟信号还会影响数字电路导致AI推理出现莫名其妙的错误。我遇到过一个典型案例视觉检测系统在实验室跑得好好的到了现场每隔几分钟就出现一次误检。排查了很久最后发现是旁边一台大功率变频器启动时电磁干扰通过电源线串进来导致图像传感器采集到一帧异常图像AI模型把这帧异常图像判成了缺陷。解决办法有几个层面。电源层面控制器和传感器用独立的隔离电源加装电源滤波器。信号层面模拟信号用屏蔽线屏蔽层单端接地数字通信用以太网的话用带屏蔽的网线或者改用光纤。软件层面AI推理程序加输入有效性检查比如连续几帧结果不一致就丢弃或者用中值滤波平滑输出。还有一个隐蔽的问题是地环路。控制器、传感器、执行器如果分别接地地电位差会形成地环路电流干扰信号采集。我的做法是整个控制系统单点接地所有设备的接地线汇到同一个接地排上。如果做不到单点接地就用隔离器或者光纤隔离信号。5.2 模型漂移与现场数据分布变化AI模型上线后准确率会随着时间下降这叫模型漂移。工业场景里模型漂移的原因主要有几个设备磨损导致振动特征变化、原料批次不同导致工艺参数变化、环境温度湿度变化影响传感器读数。我做过一个预测性维护项目模型刚上线时准确率92%三个月后降到78%。分析发现轴承磨损后振动信号的频谱特征确实变了但模型还是按新轴承的特征在判断。解决办法是定期用新数据微调模型或者在模型里加入自适应机制比如在线更新特征分布的均值和方差。但微调模型有个前提你得知道什么时候该微调。我的做法是监控推理置信度的分布。如果模型对大部分样本的置信度都很高说明数据分布跟训练时一致如果置信度普遍下降或者出现很多低置信度样本说明分布漂移了该重新训练了。还有一个实用技巧是保留一个保守的兜底逻辑。AI模型输出异常时不要直接触发停机而是先报警让人工确认。等模型稳定运行一段时间准确率验证过了再逐步放开自动控制权限。这个策略在安全相关的场景里特别重要。5.3 控制器散热与长期稳定性DC-Pi这类控制器通常是无风扇设计靠外壳散热。工业现场如果环境温度高或者柜内通风不好控制器温度会很高导致CPU降频实时性变差严重时直接死机。我实测过环境温度25度时控制器外壳温度大概45度环境温度升到40度外壳温度能到65度以上这时候CPU开始降频PLC扫描周期抖动明显增大。所以控制柜的散热设计不能省。我的做法是柜内加装风扇或者空调保证柜内温度不超过35度控制器安装时留出足够的散热空间上下左右至少留5厘米如果控制器支持加装散热片或者导热块。还有一个容易被忽略的点是灰尘。工业现场粉尘大控制器散热片积灰后散热效率大幅下降。我见过一个项目运行半年后控制器频繁过热报警打开柜子一看散热片上厚厚一层灰。后来加了防尘网定期清理问题才解决。软件层面也可以做一些保护。比如监控CPU温度超过阈值时自动降低AI推理频率优先保证PLC实时性。或者设置看门狗控制器死机时自动重启。这些机制在关键产线上是必须的。6. 这套融合方案适合谁不适合谁6.1 适合的场景特征融合控制器不是万能的它有明确的适用边界。根据我的经验以下几类场景特别适合中小型产线的智能化改造。产线规模不大控制点数在几百点以内AI需求是轻量级的异常检测或质量预测。这种场景下融合控制器一台设备搞定所有事情性价比最高。空间受限的控制柜。有些改造项目原有控制柜空间很小塞不下额外的工控机。融合控制器体积跟传统PLC差不多直接替换就行不需要改柜体。需要快速部署和远程维护的场景。融合控制器支持远程访问工程师不用到现场就能调试和更新模型。对于设备分布在不同地点的项目这个优势很明显。对数据本地化有要求的场景。有些工艺数据比较敏感不希望上传到云端。融合控制器在本地完成所有计算数据不出厂满足数据安全要求。6.2 不适合的场景与替代方案反过来以下场景我不建议用融合控制器超大规模产线。控制点数上千AI推理任务重需要多台控制器协同。这种场景下融合控制器单台算力不够不如用传统PLC加独立的边缘服务器。对实时性要求极高的运动控制。比如多轴高精度插补扫描周期要求100微秒以内。融合控制器的实时性虽然不错但跟专用运动控制器比还有差距。这种场景建议用专用运动控制器加独立的AI节点。AI模型特别大的场景。比如需要跑大语言模型做自然语言交互或者需要跑高分辨率视觉大模型。融合控制器的算力撑不住还是得用带独立显卡的工控机或者边缘服务器。已有成熟架构且运行稳定的场景。如果现有系统跑得好好的没有智能化需求没必要为了融合而融合。技术改造要有明确的收益不能为了追新技术而折腾。6.3 从传统PLC工程师转型的学习路径最后说说人的问题。融合架构对工程师的技能要求变了传统PLC工程师需要补AI和Linux的课。我的建议是分三步走。第一步先把Linux基础打牢学会用命令行、看日志、配网络、写简单的Shell脚本。这一步不用太深能排查常见问题就行。第二步学Python和基本的机器学习概念不用一上来就啃深度学习先理解什么是特征、什么是模型、什么是训练和推理。第三步找一个实际的小项目练手比如用Python读PLC变量、做个简单的异常检测、把结果写回PLC。跑通一个完整链路比看十本书都管用。转型过程中最大的障碍不是技术是思维方式的转变。传统PLC编程是确定性的输入决定输出逻辑清晰。AI是不确定性的模型输出有概率需要处理边界情况和异常。习惯确定性思维的工程师一开始会很不适应。我的经验是把AI当成一个不太靠谱的传感器它的输出需要校验、需要兜底、需要跟其他信号交叉验证。这样想心态就顺了。实际项目里我通常会让电气工程师和算法工程师结对工作。电气工程师负责定义变量、写控制逻辑、做安全兜底算法工程师负责数据处理、模型训练、推理优化。两个人一起调试互相学习对方的领域知识。几个项目下来电气工程师能看懂模型指标算法工程师能理解PLC扫描周期配合就顺畅了。融合控制器这个方向我的判断是它会逐渐成为中小型产线智能化改造的主流选择。不是因为它技术多先进而是因为它把复杂留给自己把简单留给用户。工程师不用再纠结三台设备怎么通信、怎么同步、怎么维护一台设备、一套工程、一个IP专注解决工艺问题就行。当然前提是选对场景、做好隔离、留好兜底。我在实际使用中发现只要这三点做到位融合方案的稳定性和传统架构没有区别而部署效率和维护便利性提升是实实在在的。