企业官网建设流程全解析

在工厂里跑过项目的人都懂，PLC、触摸屏、工控机这三样东西凑齐一套看似容易，真正联调起来却经常让人头大。最近用了宏集DC-Pi工业控制器，这名字听起来像块树莓派开发板，实际上它把PLC逻辑、HMI画面和边缘AI推理塞进了同一台设备里。这篇文章想和你聊聊它的融合思路，以及我在一个实际设备监测项目里跑通整个流程的体会，适合正在做非标设备、产线数字化的朋友参考。

1. 为什么工业现场需要一台“三合一”控制器

1.1 传统架构的槽点

过去做一套带“大脑”的设备，标准配置是：一台PLC负责逻辑控制，一块触摸屏做HMI，再外挂一台工控机或者边缘网关跑数据采集和AI算法。这套东西用来用去，问题都出在“三台设备之间的连接”上。

首先是协议对齐的麻烦。PLC品牌五花八门，台达、汇川、西门子、欧姆龙、AB，各自的编程软件不一样，通讯口也不一样。触摸屏要和PLC通讯，工控机也要和PLC通讯，一旦某个寄存器地址映射错一个字节，现场排查就是几小时起步。博图HMI仿真按钮无反应这类问题，在组态阶段几乎人人都碰过。其次是软件栈割裂。PLC里写梯形图的人往往不熟Python，搞边缘AI的人又不想碰梯形图，两边交付物互相看不懂，出了问题互相甩锅。

更让人头疼的是实时性和高负载的任务挤在一台工控机上。工控机跑Windows，PLC跑实时任务，AI推理又吃CPU，如果AI模型推理卡顿，PLC那边还在傻等数据响应，轻则报警，重则停机。传统架构里“逻辑控制”和“数据计算”没有分层，硬凑在一起就是互相拖后腿。

1.2 DC-Pi的定位与破局

宏集DC-Pi这款控制器，第一步就是把“三层分离”变成“一机融合”。它在硬件上提供了工业级IO接口和通讯口，可以直接接传感器、继电器、伺服驱动器；在软件上同时提供软PLC Runtime、HMI运行时环境和Linux边缘AI环境。换句话说，一台设备里既跑梯形图/结构化文本，又跑可视化界面，还能跑TensorFlow Lite或ONNX推理模型。

有人会问，这和“支持Python的PLC”有什么区别？区别在于分工。DC-Pi里的PLC Runtime是独立的一个实时域，不管Linux那边AI推理怎么折腾，逻辑控制的扫描周期不受影响。AI推理结果通过内部总线以变量的形式交给PLC程序去用，而不是让AI线程直接去拧输出继电器。这个分层隔离的设计，解决了传统架构里“AI拖垮控制”的致命问题。

从项目落地的角度看，好处相当实在：少一台工控机，少一根通讯线，少一整套地址映射表；HMI画面直接基于控制器内置的Web服务，手机浏览器就能看；AI模型可以远程更新，不用停机插网线。对于做设备智能化改造的团队来说，这套东西能把交付周期从两三个月压缩到两三周。

2. 硬件平台与软件栈：DC-Pi的核心拆解

2.1 硬件选型与接口

DC-Pi的硬件形态类似于工业级树莓派Compute Module方案，板载CPU负责跑Linux系统，同时扩展了PLC专用的IO底板。我拿到的版本接口很齐全，一组DI/DO，一组AI/AO，两个RS485/RS232串口，双网口，再配一个CAN或者EtherCAT扩展位。

这里要特别提双网口的设计。工业现场经常遇到两个网段：一个接设备网，一个接办公网。如果没有双网口，就要加网关隔离。DC-Pi一个网口接PLC和现场设备，另一个接上层MES或云平台，数据从设备网采集后格式化写进数据库，办公网那边只读结果，网络隔离上的压力小很多。

供电方面是24V工业电源输入，带反接保护和浪涌保护，这是工业控制器的基本素养。工作温度标称-20℃到70℃，无风扇设计。我自己在配电柜里装过一块，旁边就是变频器，运行了大半天，表面温度稳定在50℃上下，没有降频卡顿的情况。

提示：拿到设备先确认固件版本。DC-Pi这类融合型控制器，固件里同时包含Linux内核补丁和PLC Runtime补丁，厂家会持续更新，动工开始前先去官网对照版本号，能避开一大堆奇怪的坑。

2.2 软件生态：Codesys、Web HMI与AI Runtime

软件是DC-Pi的重头戏。PLC Runtime用的是Codesys内核，支持IEC 61131-3的LD、ST、FBD、SFC。用惯了台达、汇川的人切过来会很快，因为Codesys的编程思路和它们非常接近。如果你之前只玩过西门子博图，可能需要适应一下变量名和库的概念，但花半天时间就能上手。

HMI层面，DC-Pi没有跑传统组态软件，而是用内置的Web HMI服务。画面基于HTML5，可以直接在浏览器里打开，也可以发布成手机App的WebView页面。好处很明显，不需要单独的HMI组态工具，不依赖Windows操作系统，更不会出现“博图HMI仿真按钮无反应”这种需要改仿真器设置的尴尬。坏处也有，老一代电气工程师更习惯威纶通那种点几下就出画面的方式，Web HMI需要会一点点前端布局，但上手门槛比想象中低。

AI Runtime这部分，系统里预装了Python 3和Node-RED，支持TensorFlow Lite和ONNX Runtime。模型部署的路径很长，你可以在PC上训练好模型，转换成tflite或onnx格式，通过SSH或者Web管理页上传到DC-Pi的模型目录里，写一个推理脚本去调用。推理脚本和PLC程序之间通过共享内存变量交互，这一点是传统PLC完全做不到的。

值得一提的是DC-Pi的IDE集成方式。厂商给了统一的工程管理界面，你可以把PLC程序、HMI页面、AI模型文件打进同一个工程包，一键部署到设备上。工程包统一管理这一点，对现场交付非常关键，避免出现“PLC更新了但AI模型还是旧版”的人为失误。

3. 边缘AI落地三步走：从模型训练到PLC联动

3.1 模型怎么选、怎么转

很多人一听到边缘AI就想到深度学习大模型，其实工业场景里大多数问题用轻量模型就能解决。DC-Pi这类设备CPU算力有限，跑不了ResNet几百层的大网络，所以要按任务需求选择模型结构。

拿我做过的振动监测举例，目标是判断设备运行状态是否正常。传统做法是设置阈值，超限就报警。但设备在不同转速下，振动基线完全不一样，固定阈值经常误报。用AI做的好处是模型可以学习多转速下正常状态的特征，把误报率降下来。这类问题用随机森林、LightGBM，或者一个一维CNN就足够，不需要上大模型。

如果你偏要用视觉模型做缺陷检测，那要注意输入分辨率。边缘设备上跑YOLO系列，建议选择YOLOv5s或者YOLOv8n这种轻量版本，输入分辨率不要超过640×640，否则推理时间会让你怀疑人生。训练完成的PyTorch模型，转换成ONNX格式，再量化为INT8，通常能让推理速度提升2到3倍，精度损失在可接受范围内。

3.2 推理怎么跑起来

模型部署到DC-Pi上之后，需要写一个Python推理服务。这个服务的职责是：周期读取传感器数据，运行模型推理，把结果写进共享变量区，供PLC程序读取。

我的做法是开一个独立的Python进程，用MQTT或者共享内存和主程序通信。共享内存的方式延迟更低，DC-Pi的系统里提供了边缘变量服务，Python端往变量槽里写值，PLC端直接读这个变量，不需要经过网络协议解析。

这里有一个性能调优细节。推理服务不要用默认的Python字典存储中间结果，数据的读写延迟会累积，扫个几万次以后明显变卡。我用环形缓冲区来缓存振动波形数据，numpy数组一次性批量传给模型推理，单次推理时间从40ms降到了7ms。CPU占用在30%以内，PLC那边一点感觉都没有。

推理结果通常要打一个时间戳，把原始数据、预测值、置信度都写进SQLite本地库。DC-Pi自带SD卡存储，但工业环境建议把数据写到另一个网口挂载的NAS或者远程数据库，避免SD卡频繁写入损坏。

3.3 结果怎么回写PLC逻辑

AI推理结果要真正影响控制逻辑，不能靠“看画面手动点按钮”。DC-Pi里，推理服务算出来的状态值通过边缘变量服务写进一个系统变量，例如AI_RunningStatus。PLC程序里用ST语言或梯形图对这个变量做判断，然后执行对应的动作。

举个例子，推理模型判定设备处于“异常振动”状态，置信度0.92。Python端把AI_RunningStatus=3写入共享变量槽。PLC里写了一段逻辑：如果状态是3，且持续超过5秒，就把报警继电器置位，同时把设备转速从1000转降到800转。这一段判断加降速逻辑，在Codesys里写梯形图也就半小时的事。

这里的核心思路是：AI只做“感知和预判”，PLC做“决策和执行”。AI把从0到1的连续概率映射成枚举状态，PLC根据枚举状态做确定性的逻辑控制。这种分工让控制逻辑保持可预测性，也方便过安全认证审查。

4. 实战案例：设备振动监测与自适应告警

4.1 需求与接线

我在一个老朋友的项目里用DC-Pi替换了原本“PLC+触摸屏+工控机”的老三样。客户是生产减速机的，主要测减速机轴承振动，要求实时监测、本地HMI展示、云端报警联动。

硬件上，我在DC-Pi的AI口接了一路压电式加速度传感器信号，经过信号调理器变成4-20mA电流送到模拟量输入端。PLC侧的控制对象是设备主电机接触器和一个声光报警器。HMI用的是板载Web页面，远程运维人员通过浏览器访问控制器IP就能看到实时数据和历史曲线。

需要说明的是，虽然DC-Pi集成了AI模拟量输入，但传感器信号五花八门，压电式传感器的电荷信号必须要经过外部调理才能进AI模块，普通工业温度传感器也要注意信号类型匹配。接线前先看传感器输出是电压、电流还是通讯协议，再决定是直连还是加变送器。

4.2 从配置到跑通

第一步，给DC-Pi通电，登录Web管理页，确认Linux系统启动正常，Codesys Runtime运行中。然后在PC上安装Codesys并添加DC-Pi的设备描述文件，通过网络下载PLC工程，这跟下载台达PLC程序逻辑上类似，都是在编程软件里做通信配置，只是协议从串口换成了以太网。

第二步，配置模拟量通道。我选择AI通道对应关系，输入量程4-20mA对应0到10mm/s的振动速度量程，在Codesys里做了一次工程单位换算。采样周期设为100ms，每10个周期打包一次做特征提取。

第三步，编写推理脚本。我在PC上先用几天的历史数据训练了一个一维CNN分类模型，输入是800个采样点的振动序列，输出是正常、欠润滑、轴承磨损三个状态。模型转成ONNX INT8后上传到DC-Pi。Python推理服务启动后，持续从共享内存取振动数据，推理完成把状态值回写。

第四步，HMI页面组态。基于DC-Pi的Web HMI工具画了三个页面：实时监控、趋势分析和报警记录。实时页面显示当前振动速度、AI状态、电机启停状态，趋势页面用Chart.js画最近一小时的波形。

整个过程从接线到全流程跑通，用了大概两天半，大部分时间消耗在传感器信号干扰排查上。

4.3 实测效果与数据

跑了两周之后，数据令人满意。AI模型在验证集上的准确率大概97.3%，现场实际误报三次，都是因为外部冲击导致传感器信号毛刺，后来在推理脚本里加了滤波窗口之后，误报基本消失。

手动把轴承润滑脂抽掉一半做故障注入实验，模型在设备振动超标前约6小时就输出了“欠润滑”预警状态。这个提前量来源于对振动频带特征的持续学习，而传统阈值告警要等到振动幅值超过硬阈值才会动作，差距明显。

性能方面，PLC扫描周期稳定保持在1ms以内，即使AI推理占CPU高负载时也没有抖动。HMI页面打开延迟约600ms，在公司局域网环境下完全可接受。整个系统运行期间，CPU温度平均62℃，没有再出现过热降频。

5. 常见问题与排查技巧实录

5.1 现场高频问题速查

这些问题大部分都有共性——不是控制器本身的问题，而是边缘AI与传统PLC两套思维方式碰撞时，容易出现接口细节遗漏。比如共享变量槽的刷新机制，如果不设计一个状态计数器，下游很难分辨“推理结果是刚计算的”还是“进程卡死之前的残留值”。

5.2 我踩过的几个坑

第一个坑是模拟量采样时序。一开始我把AI推理脚本每100ms读一次共享内存，但PLC那边的采样周期也是100ms，两边节奏不一致导致数据错位。后来把推理脚本改为事件驱动，PLC每写完一帧数据就置一个标志位，脚本检测到标志位才去取数，数据对齐问题才解决。

第二个坑是模型量化后的精度跳变。同一个模型FP32转INT8之后，正常类和高磨损类的边界出现重叠，现场多报了几次“磨损预警”。后来用校准集做了量化感知训练，多加了300条正常工况样本，把精度拉回可接受范围。建议量化前先做数据增强和样本均衡，别拿原始数据集直接量化。

第三个坑是HMI页面在手机浏览器上的兼容性。最初用了大量自绘控件，在电脑浏览器上正常，一到手机的WebView里就错位。后来改成响应式布局，所有图表组件统一走一套样式库，问题解决。做设备运维的人大概率用手机看页面，HMI适配移动端这件事千万别省。

最后一个建议：给DC-Pi配一个单独的维护网口或者维护SSH账号，现场工人误操作时能快速恢复出厂配置。我在项目里把整个工程包（PLC程序+HMI资源+AI模型+配置文件）做了一次完整备份，存到NAS里，后来有一次误刷固件，半小时就恢复到可用状态。这类融合型设备，备份恢复能力做得越细，现场底气越足。

从我这几个项目的经验看，宏集DC-Pi这种“PLC+HMI+边缘AI”融合形态，现阶段最适合的场景就是中等规模、控制逻辑不算过于复杂但又需要在线智能分析的设备。没必要追求所有项目都上一体机，但如果你的设备正好是“传感器数据多、现场需要可视化、远程还要能看能调”，这台控制器会是个节省交付成本的好选择。设备方案没有绝对的标准答案，核心是想清楚实时控制和智能计算之间怎么分工，DC-Pi恰好把这道分工题做得比较清楚。