1. 工业控制器的新物种为什么要把PLC、HMI和边缘AI塞进一个盒子第一次看到宏集DC-Pi这个产品定义的时候我脑子里蹦出来的画面是一个配电柜里左边挂着西门子S7-1200右边嵌着威纶通触摸屏柜子角落还蹲着一台工控机跑着Ubuntu和Python脚本三套系统各吃各的电、各走各的线、各用各的软件生态。这种三件套组合在中小型产线、非标设备、实验台架上太常见了我自己就搭过不下二十套。问题是这套组合的痛点也极其稳定PLC负责逻辑控制HMI负责人机交互工控机负责数据采集和算法三者之间的通信要么走Modbus RTU串口轮询要么走以太网Modbus TCP要么用OPC UA做一层抽象。每加一层通信就多一层延迟、多一个故障点、多一份调试工作量。宏集DC-Pi的思路是把这三件事揉进一个基于Linux的工业控制器里。它不是简单地把三块板子拼在一起而是在同一个计算平台上同时跑PLC运行时、HMI组态环境和边缘AI推理框架。这个思路背后的逻辑很直接现代产线对控制器的要求已经不只是稳定地执行梯形图而是要在本地完成数据预处理、异常检测、预测性维护甚至简单的视觉分类同时还要把结果实时反馈到控制逻辑里。如果AI推理跑在远端服务器网络抖动和带宽成本先不说光是数据出厂的合规问题就够喝一壶的。边缘AI的价值就在于把推理放在数据产生的地方而DC-Pi把边缘AI和PLC、HMI放在同一个盒子里等于把数据产生地和决策执行地合并了。这个产品适合谁看如果你是做非标自动化设备的工程师经常被客户要求加个AI功能但又不想大动干戈改电柜DC-Pi这类产品值得研究。如果你是做PLC编程出身、想往边缘计算方向转的从业者它提供了一个不需要从头学Linux内核编译的切入点。如果你是做AI算法落地、被工控现场的实时性要求折磨过的开发者它的架构设计能给你不少启发。当然如果你只是想做简单的继电器逻辑控制那传统PLC仍然是最经济的选择没必要为了AI而AI。我写这篇东西的出发点是把这类PLCHMI边缘AI融合控制器的技术逻辑拆开讲清楚。市面上讲PLC编程的资料铺天盖地讲边缘AI部署的教程也不少但把两者放在同一个工业控制器里、讲清楚它们怎么共存、怎么分工、怎么避免互相抢资源的资料确实不多。下面我会从架构设计、核心细节、实操要点、常见问题几个维度展开尽量把我知道的、踩过的、验证过的东西都倒出来。2. 架构拆解一个Linux底座上跑三套运行时到底怎么分工2.1 硬件底座与实时性保障机制DC-Pi这类控制器的硬件底座通常是一块ARM架构或x86架构的工业级主板配上隔离DI/DO、AI/AO、RS485、以太网口等工业接口。关键不在于接口数量而在于实时性保障。Linux本身不是实时操作系统标准内核的调度延迟在毫秒级到几十毫秒级波动这对于PLC的扫描周期要求来说是不可接受的。所以这类产品一般会做两件事一是采用PREEMPT_RT实时补丁内核把内核抢占延迟压到几十微秒级别二是把PLC运行时绑定到独立CPU核心上通过CPU隔离isolcpus和实时优先级SCHED_FIFO确保PLC任务不被AI推理或HMI刷新抢走CPU时间。我实测过类似架构的控制器在四核ARM Cortex-A55平台上把PLC运行时绑到CPU3AI推理绑到CPU2HMI和系统服务跑在CPU0和CPU1上PLC的扫描周期抖动可以控制在±50微秒以内。这个数据对于绝大多数中小型设备来说完全够用。但如果你要做高速运动控制比如多轴插补那还是得用专用运动控制器或者FPGA方案通用Linux软件PLC的架构在微秒级硬实时场景下仍然有局限。这里有个容易被忽略的细节CPU隔离之后被隔离的核心上不能跑任何其他任务包括内核线程。你需要在内核启动参数里加isolcpus3 nohz_full3 rcu_nocbs3然后在应用层用sched_setaffinity把PLC运行时线程绑到CPU3。如果忘了配rcu_nocbsRCU回调线程仍然可能跑到隔离核上造成偶发的调度延迟。这个坑我在第一次部署的时候踩过PLC扫描周期偶尔会跳到200微秒以上查了半天才发现是RCU的问题。2.2 PLC运行时的选型与执行模型这类控制器上的PLC运行时常见的选择有CODESYS Runtime、Beremiz基于PLCopen、OpenPLC等。CODESYS在工业界接受度最高支持IEC 61131-3的全部五种编程语言LD、FBD、ST、IL、SFC而且有大量现成的库和驱动。宏集DC-Pi大概率也是基于CODESYS或者类似的PLCopen运行时来做PLC层。PLC运行时的执行模型是周期性扫描读输入、执行逻辑、写输出循环往复。扫描周期取决于程序规模和硬件性能一般在1毫秒到10毫秒之间。在融合控制器里PLC运行时需要和AI推理、HMI刷新共享CPU资源所以扫描周期的稳定性比绝对速度更重要。我一般建议把PLC扫描周期设为2毫秒或4毫秒留出足够的余量给其他任务。如果你把扫描周期设成1毫秒CPU负载稍微一高就可能出现扫描超时报警。PLC和AI之间的数据交换通常通过共享内存或者内部变量映射来实现。比如在CODESYS里定义一个全局变量结构体AI推理进程通过共享内存直接读写这个结构体的字段。这种方式比走Modbus TCP或OPC UA快得多延迟在微秒级。但要注意数据一致性问题如果AI进程在PLC扫描周期中间修改了共享内存PLC可能读到半新半旧的数据。解决办法是加一个双缓冲或者序列锁seqlock机制确保PLC每次读到的是一致的数据快照。2.3 HMI组态环境的运行方式与交互逻辑HMI层在这类控制器上一般有两种实现方式一种是基于Web的HMI通过浏览器访问控制器的IP地址用HTML5/JavaScript渲染界面另一种是本地HMI运行时通过HDMI或LVDS接口直接驱动触摸屏。Web HMI的好处是客户端零安装手机、平板、电脑都能看缺点是依赖网络稳定性而且浏览器渲染性能有限。本地HMI的好处是响应快、不依赖网络缺点是必须接屏幕远程访问需要额外配VNC或RDP。我个人的经验是如果设备操作员就在机器旁边本地HMI更可靠如果需要远程监控或者多终端访问Web HMI更方便。DC-Pi这类产品通常会同时支持两种方式你可以在组态软件里设计一套界面然后选择发布为Web版本还是本地版本。需要注意的是HMI刷新会占用CPU和GPU资源如果AI推理也在同一块GPU上跑可能会出现资源竞争。建议把HMI渲染绑到集成GPU上AI推理用独立NPU或者CPU避免互相干扰。HMI和PLC之间的数据绑定在CODESYS生态里通常通过符号配置Symbol Configuration来实现。你在PLC项目里把需要HMI访问的变量勾选发布HMI组态软件就能直接读到这些变量的符号名和地址。这种方式比传统的地址映射比如Modbus寄存器地址方便得多变量改名之后HMI会自动更新不需要手动改地址。但要注意发布太多变量会增加内存占用和通信负载只发布HMI真正需要的变量就行。2.4 边缘AI推理框架的部署策略边缘AI层是这类控制器区别于传统PLC的核心。常见的推理框架有TensorFlow Lite、ONNX Runtime、OpenVINOx86平台、NCNNARM平台等。选择哪个框架取决于你的模型来源和硬件平台。如果你用PyTorch训练模型导出ONNX之后用ONNX Runtime推理是最省事的路径。如果你用TensorFlowTensorFlow Lite对ARM平台的优化更好。如果你在x86平台上跑OpenVINO能充分利用CPU的AVX指令集和集成GPU。模型部署到边缘控制器上最大的挑战不是推理速度而是内存占用和模型大小。一个典型的异常检测模型比如自编码器或一维卷积网络参数量可能在几万到几十万之间量化到INT8之后模型文件大概几百KB到几MB。这个规模对于现代工业控制器的内存通常1GB到4GB来说完全不是问题。但如果你要跑视觉模型比如MobileNet或YOLO-nano模型大小可能到几MB到几十MB推理时的内存占用会更高需要留出足够的余量。推理频率是另一个需要仔细设计的参数。PLC扫描周期是毫秒级但AI推理不需要跑那么快。对于温度、压力、振动这类慢变量每秒推理一次甚至每十秒推理一次就够了。对于视觉检测可能需要每秒5到10帧。关键是不要让AI推理阻塞PLC扫描。我的做法是把AI推理放在独立线程里通过环形缓冲区ring buffer和PLC交换数据。PLC每个扫描周期从缓冲区读最新结果如果缓冲区为空就沿用上一次的结果。这样即使AI推理偶尔卡顿PLC也不会受影响。3. 核心细节从PLC编程到AI模型部署的完整链路3.1 PLC编程入门与CODESYS工程结构如果你之前只用过西门子博图或者三菱GX Works转到CODESYS生态需要适应几个差异。首先是工程结构CODESYS的项目文件.project包含设备树、应用、任务配置、库引用等。设备树里你可以添加PLC逻辑控制器、HMI可视化、运动控制轴等对象。任务配置决定了各个程序组织单元POU的执行周期和优先级。我一般会建三个任务一个2毫秒的高速任务跑安全逻辑和IO刷新一个10毫秒的中速任务跑过程控制一个100毫秒的低速任务跑数据记录和AI交互。CODESYS支持IEC 61131-3的全部语言但实际项目里用得最多的是梯形图LD和结构化文本ST。梯形图适合写逻辑联锁和顺序控制直观易懂现场调试方便。结构化文本适合写复杂计算和算法代码紧凑可读性好。我的习惯是安全逻辑和手动操作逻辑用梯形图PID控制和数据处理用ST。这样既保证了可维护性又兼顾了开发效率。一个容易被忽略的细节是变量命名规范。在融合控制器里PLC变量不仅要给HMI看还要给AI进程看。如果变量名起得乱七八糟后面做数据映射的时候会非常痛苦。我建议采用匈牙利命名法加前缀i_表示输入q_表示输出m_表示中间变量s_表示结构体。比如i_TempZone1、q_HeaterZone1、m_PIDOutput。这样在HMI组态和AI数据映射的时候一眼就能看出变量方向。3.2 HMI组态工具的选择与界面设计要点HMI组态工具的选择取决于PLC运行时的生态。如果PLC层用的是CODESYS那HMI层通常也用CODESYS Visualization因为变量绑定是原生的不需要额外配置通信驱动。CODESYS Visualization支持矢量图形、动画、趋势图、报警管理等功能做出来的界面虽然不如专业HMI软件那么华丽但功能完全够用。界面设计有几个实操要点。第一不要在一屏里塞太多信息。操作员在机器旁边站着看屏幕视线停留时间很短关键数据要放在屏幕上半部分字号要大。第二报警信息要分级紧急报警用红色闪烁警告用黄色常亮提示用蓝色。第三按钮要有防误触设计关键操作按钮需要长按或者二次确认。第四趋势图的时间轴不要设太长30分钟到2小时就够了太长的话刷新负载高而且操作员也看不清细节。如果你用的是Web HMI还要考虑浏览器兼容性。工业现场可能还在用Windows 7上的IE浏览器所以组态的时候要避免使用太新的CSS特性。我一般会用Bootstrap 3或者更早的框架来做Web HMI确保在老旧浏览器上也能正常显示。另外Web HMI的刷新频率不要设太高1秒一次就够了设成100毫秒反而会让浏览器卡顿。3.3 边缘AI模型训练与量化部署流程边缘AI的模型训练通常在PC或服务器上完成然后导出成边缘设备能跑的格式。以异常检测为例典型的流程是采集正常工况下的传感器数据温度、压力、振动、电流等做特征工程或者直接用原始时序数据训练一个自编码器或者一维卷积网络然后用正常数据验证重构误差阈值。推理的时候如果重构误差超过阈值就判定为异常。模型量化是部署前的关键步骤。FP32模型在ARM CPU上推理速度可能只有每秒几次量化到INT8之后速度能提升2到4倍模型大小缩小到四分之一。TensorFlow Lite和ONNX Runtime都支持训练后量化Post-Training Quantization只需要提供一批校准数据不需要重新训练。校准数据要从实际工况里采覆盖各种正常和边界情况否则量化后的模型精度会掉得很厉害。我试过一个振动异常检测模型用实验室数据校准之后在现场数据上误报率高达30%后来用现场数据重新校准误报率降到了5%以下。模型部署到控制器上之后还需要一个推理调度器来管理推理频率和资源占用。我的做法是写一个Python脚本用schedule库或者简单的time.sleep循环来控制推理节奏推理结果写入共享内存或者MQTT主题。PLC通过共享内存读取结果HMI通过MQTT订阅结果。这样AI进程和PLC、HMI之间是松耦合的AI进程崩溃了也不会影响PLC运行。3.4 三套运行时的数据交换与同步机制PLC、HMI、AI三套运行时之间的数据交换是融合控制器最核心也最容易出问题的环节。常见的数据通道有三种共享内存、MQTT、OPC UA。共享内存最快适合PLC和AI之间的高频数据交换MQTT最灵活适合HMI和AI之间的异步通信OPC UA最规范适合和外部系统集成。共享内存的实现方式在Linux上一般用POSIX共享内存shm_openmmap或者System V共享内存shmgetshmat。CODESYS Runtime通常提供共享内存接口你可以把PLC变量映射到共享内存区域AI进程直接读写。需要注意的是字节对齐和数据类型匹配PLC里的REAL类型是4字节浮点数AI进程读的时候也要按4字节浮点数解析否则会读出乱码。我一般会在共享内存区域头部放一个结构体定义两边用同一份头文件避免手动对齐出错。MQTT适合传输JSON格式的结构化数据比如AI推理结果、报警信息、统计数据。HMI可以通过MQTT客户端订阅这些主题实时更新界面。MQTT的QoS等级建议设为1至少一次QoS 2恰好一次的开销太大工业现场没必要。Broker可以跑在控制器本地比如Mosquitto也可以跑在边缘网关或云端。如果跑在本地要注意Broker进程的资源占用别让它把CPU吃满了。OPC UA适合和SCADA、MES、ERP等上层系统集成。CODESYS Runtime通常内置OPC UA服务器你可以把需要暴露的变量添加到OPC UA地址空间上层系统通过OPC UA客户端读取。OPC UA的安全性比Modbus TCP好得多支持加密和认证但配置也复杂得多。如果只是内部使用Modbus TCP更简单如果要和外部系统对接OPC UA更规范。4. 实操过程从零搭建一个带AI异常检测的温控系统4.1 硬件接线与控制器初始化假设我们要搭建一个温控系统两个加热区各配一个热电偶K型和一个固态继电器SSR控制器用DC-Pi目标是把两个区的温度稳定在设定值同时用AI检测加热器老化异常。硬件接线方面热电偶信号接入控制器的AI通道注意热电偶极性K型热电偶负极是红色SSR控制信号从DO通道输出注意SSR是电压驱动还是电流驱动多数SSR是3-32VDC驱动可以直接接24V DO。以太网口接交换机HMI屏幕通过HDMI接控制器。控制器初始化第一步是刷系统。DC-Pi这类产品通常提供预装镜像烧写到eMMC或SD卡之后上电启动。首次启动后要配置网络静态IP还是DHCP工业现场建议用静态IP避免IP冲突导致失联。配置命令在Linux下就是改/etc/network/interfaces或者用nmcli。我一般会配两个IP一个用于HMI和调试比如192.168.1.100一个用于PLC通信比如192.168.10.100物理上走同一个网口但逻辑隔离。然后是安装运行时。CODESYS Runtime通常以deb包或者tar.gz形式提供安装之后需要配置许可证和启动服务。许可证文件要放在指定目录启动服务用systemctl管理。安装完成后用CODESYS Development SystemWindows上的IDE通过以太网扫描设备应该能看到控制器节点。如果扫描不到检查防火墙是否放行了CODESYS的通信端口默认1217和11740。4.2 PLC程序编写温度PID与逻辑联锁温度PID控制是经典场景但现场调试的时候温差波动大是常见问题。PLC温度PID波动温差大如何调节我的经验是分三步走先调采样周期再调PID参数最后加前馈补偿。采样周期建议设为PID积分时间的十分之一到五分之一。比如积分时间设100秒采样周期就设10到20秒。如果采样周期太短热电偶噪声会被放大PID输出抖动厉害采样周期太长控制不及时温度会过冲。PID参数整定我一般用齐格勒-尼科尔斯法粗调然后手动微调。先把积分时间和微分时间设为零只加比例增益直到系统出现等幅振荡记录临界增益Ku和振荡周期Tu。然后按表设置P控制时Kp0.5KuPI控制时Kp0.45KuTi0.83TuPID控制时Kp0.6KuTi0.5TuTd0.125Tu。这套参数是起点实际还要根据系统惯性和滞后调整。加热系统通常滞后大微分时间可以适当加大但太大又会对噪声敏感需要折中。逻辑联锁方面至少要加超温保护温度超过设定值加20度时强制切断加热输出并触发报警。这个保护逻辑要放在高速任务里扫描周期2毫秒确保及时响应。另外SSR故障检测也很有用如果DO输出为ON但温度持续下降说明SSR可能开路如果DO输出为OFF但温度持续上升说明SSR可能短路。这两种情况都要报警并切断主回路。4.3 AI异常检测模型的训练与部署加热器老化异常检测我用的方案是采集正常加热阶段的电流和温度数据训练一个自编码器输入是电流和温度的时序窗口比如30秒窗口每秒一个采样点共30个点输出是重构后的窗口。正常数据的重构误差小异常数据的重构误差大。阈值设为正常数据重构误差的95分位数。数据采集用PLC的模拟量输入通道电流用霍尔传感器转成0-10V信号温度用热电偶变送器转成0-10V信号。采样率1Hz采集至少24小时的正常数据覆盖不同的环境温度和负载条件。数据存成CSV在PC上用PyTorch训练自编码器。网络结构不用太复杂输入层30维编码层16维瓶颈层8维解码层16维输出层30维。激活函数用ReLU损失函数用MSE优化器用Adam学习率0.001训练100个epoch。训练完成后导出ONNX模型用ONNX Runtime的量化工具做INT8量化。校准数据从训练数据里随机抽1000个窗口。量化后的模型大小大概几十KB在ARM CPU上推理一次大概几毫秒。部署到控制器上用Python脚本加载ONNX模型从共享内存读取PLC的电流和温度数据组成30秒窗口推理得到重构误差和阈值比较结果写回共享内存。PLC在低速任务里读取AI结果如果连续3个推理周期都判定异常就触发报警。4.4 HMI界面设计与报警联动HMI界面我设计了三个页面主监控页、趋势页、报警页。主监控页显示两个区的当前温度、设定温度、加热输出百分比、AI异常状态。趋势页显示两个区的温度曲线时间轴30分钟。报警页显示当前报警和历史报警支持确认和复位。报警联动方面PLC里的超温报警和AI异常报警都映射到HMI的报警变量。HMI检测到报警变量为TRUE时弹出报警条同时记录报警时间和类型。报警确认按钮写回PLC一个布尔变量PLC收到确认后清除报警状态。需要注意的是报警确认不能直接清除报警原因只是确认操作员已经知道。如果报警原因仍然存在报警应该保持激活状态只是从未确认变成已确认。Web HMI的访问我配了Nginx做反向代理把CODESYS Visualization的Web服务代理到80端口。外部设备通过浏览器访问控制器IP就能看到HMI界面。Nginx配置里加了Basic Auth防止未授权访问。如果现场有多个操作终端可以在路由器上做端口映射但要注意安全风险建议只在局域网内访问。5. 常见问题与排查技巧实录5.1 PLC与HMI通信异常排查博图HMI仿真按钮无反应是西门子生态里的经典问题但在CODESYS生态里也有类似的坑。最常见的原因是变量没有发布到HMI。在CODESYS里PLC变量默认是不对HMI可见的你需要在符号配置里勾选发布或者把变量加到HMI访问列表里。如果忘了这一步HMI组态的时候能看到变量名但运行时读写都是无效的。另一个常见原因是HMI和PLC的通信端口被防火墙拦截。CODESYS的HMI和PLC之间走的是内部通信不经过以太网所以一般不受防火墙影响。但如果你用的是Web HMI浏览器和控制器之间的HTTP/WebSocket通信可能被防火墙拦截。检查控制器的iptables规则确保80端口和WebSocket端口通常是8080或443是放行的。还有一种情况是HMI刷新频率太高导致通信超时。CODESYS Visualization的默认刷新周期是100毫秒如果页面元素太多刷新一次可能超过100毫秒导致通信队列积压。解决办法是降低刷新频率到200毫秒或500毫秒或者把不重要的元素设为按需刷新。5.2 AI推理性能不达预期的优化思路AI推理慢首先要定位瓶颈在哪儿。用top或htop看CPU占用如果推理进程CPU占用100%但推理速度还是很慢说明模型太大或者算子没有优化。用perf工具做性能分析看时间花在哪个算子上。常见的瓶颈是卷积算子ARM CPU上的卷积优化不如x86可以考虑用NCNN或者TFLite的ARM优化版本。如果CPU占用不高但推理速度慢可能是内存带宽瓶颈。模型量化到INT8之后内存访问量减少速度应该会提升。如果量化后速度没变检查推理框架是否真的用了INT8算子。ONNX Runtime需要设置intra_op_num_threads和execution_modeTFLite需要设置num_threads。另外把推理线程绑到独立CPU核心上避免和PLC、HMI抢资源。还有一个容易被忽略的点是模型输入预处理。如果预处理用Python的PIL或NumPy做可能比推理本身还慢。解决办法是用C写预处理或者用OpenCV的C接口。如果预处理是简单的归一化和缩放直接在推理框架的输入层做不要单独写Python代码。5.3 系统资源竞争与实时性保障融合控制器最常见的系统问题是资源竞争。PLC扫描周期抖动、HMI界面卡顿、AI推理超时根源往往是CPU、内存、IO资源被某个进程独占。排查方法是先用top看CPU占用用free看内存占用用iostat看IO负载。如果发现某个进程占用异常用strace跟踪系统调用看它在干什么。CPU隔离是保障实时性的关键。除了前面说的isolcpus和nohz_full还要注意中断亲和性。默认情况下所有中断都分配到CPU0如果CPU0上还跑着HMI和系统服务中断处理可能会延迟PLC任务。解决办法是把中断分配到非隔离核心上或者用irqbalance做中断负载均衡。对于关键中断比如以太网中断可以手动绑到特定核心。内存方面要注意避免交换swap。工业控制器上最好禁用swap因为swap的IO延迟不可控会导致PLC扫描周期抖动。禁用swap的命令是swapoff -a然后在/etc/fstab里注释掉swap分区。另外给PLC运行时和AI推理进程设置内存锁定mlockall防止内存页被换出。5.4 常见问题速查表问题现象可能原因排查方法解决方案PLC扫描周期抖动大CPU被其他进程抢占用top看CPU占用用cyclictest测延迟隔离CPU核心绑定PLC线程禁用swapHMI按钮无响应变量未发布或通信超时检查符号配置用Wireshark抓包发布变量降低刷新频率检查防火墙AI推理速度慢模型未量化或线程数不足用perf分析热点检查推理框架配置量化模型设置线程数绑定CPU核心温度PID波动大采样周期不当或PID参数不合适记录温度曲线分析振荡周期调整采样周期重新整定PID参数共享内存数据错乱字节对齐或数据类型不匹配检查两边结构体定义打印原始字节统一头文件加序列锁或双缓冲控制器无法启动系统镜像损坏或存储故障接串口看启动日志重新烧写镜像更换存储卡网络通信中断IP冲突或网线故障用ping和arp检查改静态IP换网线检查交换机AI误报率高校准数据不具代表性对比训练数据和现场数据分布用现场数据重新校准调整阈值6. 从PLC工程师到边缘AI落地者的技能迁移路径做了十几年PLC编程转到边缘AI落地最大的障碍不是编程语言而是思维方式。PLC编程是确定性的输入确定逻辑确定输出确定。AI推理是概率性的同样的输入输出可能略有不同训练数据没覆盖的情况输出可能完全离谱。这两种思维在融合控制器里必须共存而且不能互相干扰。我的做法是把AI定位为辅助决策而不是直接控制。AI的输出不直接驱动执行器而是作为PLC逻辑的一个输入条件。比如AI检测到加热器异常它不直接切断加热而是把一个布尔标志写给PLCPLC根据这个标志和当前工况决定是否切断。这样即使AI误报PLC还有机会做二次判断。同理AI的异常检测结果也不直接触发停机而是触发报警由操作员确认后再决定是否停机。技能迁移的具体路径我建议分三步走。第一步熟悉Linux基本操作和Python编程。不需要学到内核编译的程度但至少要会看日志、改配置、写脚本。第二步学一个深度学习框架PyTorch或TensorFlow都行重点学数据预处理、模型训练、模型导出。第三步学边缘推理框架的部署ONNX Runtime或TFLite重点学量化、线程配置、性能调优。这三步走下来大概需要三到六个月取决于你每天能投入多少时间。最后分享一个我踩过的坑不要试图在控制器上训练模型。控制器的CPU和内存资源有限训练一个稍微大点的模型可能要几个小时甚至几天而且训练过程中CPU满载PLC扫描周期肯定受影响。训练必须在PC或服务器上做控制器只负责推理。模型更新的时候通过U盘或者网络把新模型文件传到控制器上重启推理进程加载新模型。这个过程可以做成自动化的但初期手动操作更可控。