企业官网建设流程全解析

1. 三层割裂的老大难：PLC只管逻辑、HMI只管显示、AI盒子只管分析

做工业控制这么多年，我一直觉得产线调试最耗心力的不是设备本身，而是"让三样东西互相理解"——PLC、触摸屏、还有这两年新加进来的AI分析盒子。

去年在客户现场调一套注塑机数据采集系统，现场是这样的布局：西门子S7-1200做逻辑控制，国产触摸屏挂在柜门上显示参数，外加一台单独的小工控机跑视觉检测。三个设备来自三家供应商，通讯协议没有一个统一的。触摸屏要读PLC的M区变量，得先在屏的组态软件里把地址一个个填进去；AI工控机要拿数据，只能走Modbus TCP轮询；出问题的时候，三个厂商的售后互相甩锅，说"我们这边没问题，你问另一家"。那一周我基本就是在翻协议文档和打电话里度过的。

其实这不是个别现象。传统工业控制架构里，PLC、HMI、边缘AI天然就是三件套，各自有各自的软件链、各自的变量体系、各自的调试工具。PLC工程师写梯形图的时候有一套习惯，HMI工程师组态画面又是另一个路子，搞边缘AI的人进来之后还得再学一遍OPC UA和点位表。数据层层转发，延迟高不说，点位对不上是家常便饭。

所以当我第一次接触到宏集DC-Pi这个把PLC、HMI、边缘AI塞进同一台控制器的方案时，第一反应是"终于有人愿意做这种整合了"。这篇文章我就用实际使用体验，说说这类三合一控制器到底解决了什么问题，以及它实际落地时有哪些坑。

先说清楚这东西是给谁用的。如果你在做设备改造、OEM设备电气设计、或者实验室自动化项目，手头需要一套能跑逻辑控制、能做人机界面、还能塞下AI推理模型的紧凑型控制器，那DC-Pi这种路线会很对胃口。如果你们厂里已经是成熟的西门子加WinCC架构，采购流程也不大有弹性，那短期内没必要动，但了解一下趋势没坏处。

2. DC-Pi的家底：软PLC实时核、Linux应用核和一套共享内存

DC-Pi这个名字里，"DC"是直接控制或者分布式控制的缩写，不同资料里写法略有出入，但"Pi"是明确的——树莓派计算模块。宏集这套控制器以树莓派CM4作为核心硬件，再叠加自己设计的工业级载板，把电源、隔离IO、通讯接口和外壳做成真正的工业控制器形态。

听起来简单，但这里有个关键设计逻辑值得展开：软PLC的实时性到底怎么保证。树莓派跑的是Linux系统，Linux不是硬实时操作系统，直接在上面跑PLC逻辑肯定会出问题——一个中断抢占就可能让扫描周期抖动几毫秒，这在伺服控制里是不能忍的。DC-Pi的方案是把CPU资源做隔离和优先级分层，PLC运行时（RT层）跑在优先级最高的核上，使用PREEMPT_RT补丁或类似机制保证周期确定性；HMI渲染、AI推理、网络通讯这些非实时任务分到别的核上跑普通Linux进程。两者之间通过共享内存交换数据，不需要走网络协议。

2.1 一张图看明白三合一架构的分工

不画拓扑图了，用文字描述：

• 控制层：Codesys或兼容IEC 61131-3的软PLC运行时，支持ST、梯形图、FBD等语言，负责逻辑控制、运动控制、现场总线主站。
• 交互层：HMI运行时直接跑在同一套Linux系统里，通过共享变量接口读写PLC的符号表，渲染触摸屏页面。
• 智能层：Python/Node-RED等应用程序跑在应用容器里，可调用OpenVINO、TensorFlow Lite这类推理引擎，通过共享内存或者MQTT走本地回环拿PLC数据。

关键点在于，这三层之间不是"三个系统通过网络对话"，而是同一个系统里三个进程共享内存。变量在PLC程序里声明一次，HMI和AI应用直接引用同一个内存地址，消除了传统架构里那一大堆点位映射和协议转换的开销。

2.2 为什么选树莓派CM4而不是x86

身边总有工程师问我，同样的价格，弄一台x86工业小主机跑Codesys和Python不是性能更强吗？这里有个取舍问题。

CM4的好处是功耗和体积，整机功耗通常就十几瓦，无风扇环境下靠着铝制外壳散热就能稳定运行。很多设备机柜里没有专门的制冷，一台发热大的工控机反而难处理。CM4的板载IO能力也够用——双千兆网口、USB 3.0、HDMI显示接口，配宽温载板之后扩展RS485、CAN、DI/DO都很方便。

缺点是算力确实有限。CM4的4核A72跑AI模型没问题，但别指望跑大模型或者高分辨率实时视频流分析。后面会讲，边缘AI落地的关键是把问题规模压缩到和算力匹配的程度，而不是硬上大模型。

3. PLC与HMI的同源合体：变量一次声明，两边同时生效

说实在的，PLC和HMI集成到同一台设备里，最大的收益不是省了那根通讯线，而是开发体验和工程效率。这里我展开讲几个实际操作层面的变化。

传统HMI组态时最痛苦的环节是什么？地址绑定。你在HMI软件里画了一个"当前温度"显示框，然后得在属性面板里手动填上对应的PLC地址，比如%MW100。填错一个字节，屏上显示的数值就完全不对。项目工程大的时候，几百个地址挨个核对，眼睛真的会花。更麻烦的是，如果PLC程序里改动了变量映射，HMI这边不会自动同步，得手动重新绑定。

DC-Pi这类同源方案的逻辑不一样：PLC程序里声明的变量（在Codesys里叫变量或者全局变量列表），HMI编辑器直接以符号表的方式引用。换句话说，屏上的画面控件绑定的不是"PLC里的第100号寄存器"这种物理地址，而是绑定一个带名字的符号，比如"Oven_Temperature"。PLC程序里换地址、换存储位置，只要符号名不变，HMI不用做任何改动。

3.1 实际做画面开发时的工作流变化

以DC-Pi的开发工具包为例（他们近期更新的HMI工具包V6.3），整个流程大概是这样的：

1. 先用Codesys写好逻辑控制程序，在全局变量列表里定义好所有需要上屏的变量。
2. 编译下载到DC-Pi之后，HMI组态软件单独启动，它会自动识别到本机的运行时实例，拉取符号表。
3. 组态画面时，拖一个文本显示控件，在变量绑定对话框里直接搜索"温度"或者"Oven"，选中对应符号就行。
4. 画面支持的本机标签页、数据记录、报警列表都可以直接引用符号表里的变量，甚至报警触发条件都不用再写一遍表达式。

这个工作流对一个工程师来说意味着什么？意味着一个人可以做完整套逻辑加HMI，不用在PLC工程师和HMI工程师之间来回传达需求。中小型设备改造项目，交付周期能压缩一大截。我去年拿这套做一台小型包装设备的项目，从写PLC逻辑到画面做出来，一共花了两个晚上，这在以前至少是一个星期的工作量。

3.2 在线调试和改动流程的简化

还有一个小细节，实际用起来特别舒服：普通HMI改画面之后到底要不要重新下载整个工程？有些老牌HMI软件改一个页面脚本就得整体编译下载，程序一旦跑起来，中途改画面很麻烦，得停机。

DC-Pi的HMI运行时支持页面级热更新，就是说跑生产的时候发现某个按钮标签写错了、某个数值框绑错符号了，在开发端直接改了那一个页面，单独下发这个资源就行，PLC程序不用重启、产线不用停机。当然，前提是你不要动到页面公共脚本和全局资源，那个还是得整包更新。这个能力在调试阶段特别救命，减少了很多不必要的停产等待。

4. 边缘AI不是摆个模型那么简单：从数据管道到推理上线的完整链路

说完了PLC和HMI的部分，重点来了——边缘AI。这两年谁做工业自动化都绕不开这个词，但真正落地的案例并不多。我分析过原因，很多时候不是算法不行，而是数据管道没打通。模型训练得再好，拿不到生产现场的高质量实时数据，一切都白搭。

DC-Pi这类设备在数据管道上的优势是天然的：AI应用和PLC运行在同一个系统里，数据不需要出设备。你可以直接读取PLC符号表里的实时值、报警状态、当前配方号，也可以自己采样IO点，以毫秒级频率做分析。这和传统方案里用OPC UA从PLC那拉数据再到云端分析的路径，延迟和数据新鲜度完全不是一回事。

4.1 工业现场做AI的正确打开方式

做边缘AI落地，我个人建议的优先级是：先做设备状态监测，再做视觉质检，最后才碰预测优化。设备状态监测（比如电机振动异常、轴承磨损、电流谐波波动）数据容易采集，模型输出也容易解释——报警、停机、建议维护，维护工程师本来就认可这套逻辑。视觉质检要做就做好光源和工装，不然会被现场环境光干扰搞死。预测优化这类直接触碰工艺参数的建议，千万不要一上来就做，因为现场老师傅不信任你，你敢自动调参数他们就敢拉闸。

用DC-Pi做振动监测的一个典型配置是：振动传感器通过Modbus RTU接到载板的RS485口，PLC循环读取数据，边采集边做FFT变换，提取轴承特征频率（BPFO、BPFI这些），然后喂给一个轻量级分类模型，判断是否处于异常状态。模型推理如果用的是Python脚本，可以直接调用自带推理引擎，跑一次推理大约几十毫秒，对秒级响应的监测需求完全够用。

4.2 模型部署怎么选：本地推理引擎还是MOTT中转

在实际项目里，模型推到DC-Pi上有两种方式：

一个是在本机直接跑推理。这样延迟最低、不依赖网络，适合实时性要求高的场合，比如分拣机上的瑕疵判断（配合相机，不过相机一般走USB或者千兆网口接入）。另一种是把DC-Pi当数据网关，数据在本地做预处理，然后打上时间戳推送MQTT到边缘服务器或者云端跑重模型。这种做法适合模型大、算力不够的场景，但就要注意网络稳定性和断网缓存的问题。

考虑到CM4的算力，我通常的做法是：模型在训练阶段先剪枝量化，用INT8量化把模型体积压到三分之一以下，推理速度提高两到三倍，精度损失控制在2%以内，然后本机部署。实在压缩不下去的模型才走MQTT转发。实测下来，一个两分类的振动异常检测模型，量化后不到10MB，在老版本OpenVINO上每帧推理也就20毫秒不到，压根不需要上云。

4.3 好用的调试帮手：Node-RED和图形化数据流

很多做PLC的工程师对Python不熟，直接让他们写推理脚本不现实。好在DC-Pi预置了Node-RED这类图形化数据流工具，你可以在画布上拖拽节点，把"PLC读取变量节点""数据预处理函数节点""HTTP请求节点"连起来，不用写太多代码就能搭出一条AI数据管线。

这个设计我觉得很聪明，比硬逼着工控工程师学Python实在多了。它把"AI能力"封装成了一个个可拖拽的节点，让你用组态的思路去做数据流。我最早用熟悉它是做了一个能耗监测：PLC读取三相电参数，Node-RED每5秒打包一次数据，本地做一个用电异常的三分类判断，结果写回PLC的某个M区，HMI上显示"正常""偏高""异常"三种颜色。从开始搭到上线大概用了一天，大部分时间花在调传感器的数据格式上。

5. 现场实测半年后，我记下的五个坑和一个惊喜

任何新东西都有它的脾性，DC-Pi这类产品也不例外。我用了半年多，总结了几条值得注意的地方，希望能帮准备入手的同行少走弯路。

5.1 坑一：实时性和PC机的"实时"不是一个东西

第一批用软PLC的工程师往往有个误解：觉得PC端的软PLC性能强，能靠高主频把运动控制"暴力算过去"。不是的。运动控制，尤其是EtherCAT总线伺服同步，对时间确定性要求极高——周期必须稳定，不能偶尔快偶尔慢。DC-Pi虽然做了实时性优化，但它的实时能力比专用运动控制PLC还是有差距的，而且CM4本身的主频也有限。

实测中，DC-Pi跑EtherCAT从站数量少（十几轴以内）、循环周期在2ms以上时非常稳定；但如果要做到几百微秒的同步周期、几十个伺服轴，它就不合适了。这不是坏，是定位问题。咱不能拿它替高端运动控制器，但做常规逻辑控制、过程控制、数据采集，它富余得很。

5.2 坑二：掉电保护一定要自己动手做

树莓派CM4用的存储是eMMC，频繁掉电有文件系统损坏的风险。工业现场最不缺的就是突然断电，尤其老旧车间，空开一拉整柜全灭。我一开始以为厂家出厂设置了只读文件系统或者掉电保护，实际测下来发现没那么全——应用层的文件写入还是要自己注意。

我的做法是：把AI模型的临时文件、日志目录挂到内存盘（tmpfs）里，避免频繁写eMMC；正式数据要落盘的话，用支持掉电保护的数据库或者直接走远程存储；此外系统层面配置了看门狗，万一系统挂死可以自动重启，但重启后PLC程序必须能自恢复，这点要在程序里做启动状态保存和恢复逻辑。别偷懒，工业现场的掉电频次远比你以为的高。

5.3 坑三：散热没你想的乐观

CM4在满负荷跑AI推理的时候发热不小，如果外壳散热片不够，重载推理持续几十分钟后，CPU会降频保护。降频之后实时性会跟着受影响，因为RT核虽然是隔离的，但散热是共享的。温度一上来，整体性能都会掉。

建议在选型之初就考虑加装导热的安装背板、柜内风扇，或者把推理任务做成"间歇式"的，比如每5秒拍一次样做一次分析，而不是持续满负荷跑。实测下来，间歇推理模式不光温度低很多，eMMC的寿命压力也小。

5.4 坑四：AI与IO控制的联动逻辑要想清楚

把AI推理结果直接写回PLC控制输出，听起来很顺，但真的踩过坑。我之前做的一个项目，AI识别到传送带上的产品表面有缺陷，就想直接让PLC把这件产品推入次品区。结果推理延迟不稳定，快的时候几十毫秒、慢的时候几百毫秒，导致推杆动作时机飘。还好PLC程序里加了产品位置到达检测，用光电开关同步位置，AI只给出"这件要不要剔除"的判断，真正的执行时机由光电开关触发，这个问题才解决。

记住一个原则：AI只负责做"是什么"的判断，PLC负责做"什么时候动"的执行。把时间和顺序的控制权留在PLC里，边缘AI的输出进入PLC的逻辑层时要做滤波、去抖、超时判断。别把AI当快准狠的实时执行器。

5.5 坑五：HMI和AI抢占CPU资源时的调度问题

设备偶尔出现卡顿，排查了很久，发现是两个任务同时在跑：HMI在加载一个大页面，AI在跑推理，导致Linux调度一时没调整过来，触摸屏的响应变慢了。这个在工控现场很要命——操作工切了两下屏幕没反应，就会怀疑是设备死机，直接按急停。

厂家后来在工具包更新里调了进程优先级，但我也学到一个习惯：HMI页面不要单页塞太多大图和复杂动效，AI推理任务尤其要注意限制CPU占用率，必要时在脚本里加个sleep间隔，不要让它长时间霸占多核。这类"性能和体验"的平衡，需要你在做项目时亲自调一调，每个项目的负载都不一样。

5.6 一个惊喜：老设备改造的契合度

原本我有点担心，Linux底座、Codesys、Python都塞在一个盒子里，用起来会不会"四不像"。实际跑下来发现，对老设备改造反而是最顺的场景——老压机、老注塑机、老包装线，原来要么没有PLC，要么PLC非常老旧，通信口都不好找。DC-Pi因为有丰富的网关能力（Modbus RTU/TCP、Profinet转账Modbus这类的协议转换都支持），可以直接挂到老设备上，一边接手控制逻辑，一边做数据采集和状态监测。很多"再买一整条新产线太贵，旧设备又不敢扔"的企业，用这种方案花很少的钱就把设备"智能化"了。

6. 和传统方案的对比：什么时候该选三合一，什么时候别碰

最后给想入手的同行整理个参考。我不喜欢绝对化的结论，但有几个判断标准是清晰的：

如果你是这样的场景，DC-Pi这类三合一控制器非常香：设备数量多、单机逻辑不太复杂、预算有限、现场空间紧凑、希望快速部署边缘AI又不想搞一柜子的网关和工控机。尤其是OEM设备、小型自动化改造、实训实验台、科研数据采集，这套东西几乎是量身定做。

如果是下面这些场景，就别硬上：需要SIL3安全认证的安全回路（它没有系统性的安全认证体系）、几百轴高速同步运动控制、超大HMI画面量和复杂的报表系统、对操作系统底层有特殊合规要求的军工医药项目。这些场合老老实实分体式方案，各司其职更稳妥。

用toc HL我会给出这样的标准：当你的项目在"逻辑不太复杂、有AI需求、空间紧张、预算敏感"这四点占了至少三点时，就不用纠结了。反之，任何一点踩到红线（比如安全保障），都别把宝压在一台多功能设备上。工具是拿来解决问题的，不是拿来标榜先进的。

我自己在实际使用中的体会是，这类"三合一"设备最大的价值，不是单项性能参数有多漂亮，而是给了中小型自动化项目一种新的工程组织方式：一名工程师从头到尾写完逻辑、画面和AI逻辑，交付时手里就一个设备、一套备份文件、一批文档，不再需要协调三家供应商。这种"少折腾"的踏实感，在工业现场比任何浮夸的技术参数都珍贵。