1. 控制层正在发生什么从两层皮到一张网干了十几年自动化我见过太多工厂里 IT 和 OT 各玩各的场面。IT 那边抱着虚拟化、容器、微服务天天讲敏捷迭代OT 这边守着 PLC、DCS、现场总线一个逻辑改动要走三天审批。两边开会IT 说 OT 太保守OT 说 IT 不懂现场最后项目卡在最后 100 米——数据从产线到机房这段路谁都推不动。这两年情况变了。软件 PLC、确定性网络、AI 进入控制层这三件事凑到一起把原来那堵墙凿开了一个口子。我最近参与的几个改造项目控制层的形态跟五年前完全不是一回事PLC 跑在工控机的容器里网络用 TSN 做时间同步AI 模型直接挂在控制回路旁边做参数寻优。这不是概念演示是已经在跑的产线。这篇东西写给两类人看。一类是 OT 侧的工程师你可能正在被要求上云接 MES做数据采集但不知道控制层该怎么改另一类是 IT 侧的开发或架构你想把软件工程那套东西带进车间但被现场总线和实时性要求劝退过。我会把这三块技术的核心逻辑、选型考量、实操步骤、踩过的坑都摊开讲尽量让你看完能判断自己的项目适不适合动、怎么动。先说清楚一个前提IT/OT 融合不是把 IT 那套原样搬到 OT。控制层有它自己的物理约束——微秒级的抖动可能让伺服报警网络丢一个包可能让机械手撞机。所以下面讲的所有方案都是在这个约束下做的折中不是纯 IT 视角的理想架构。2. 软件 PLC把控制逻辑从专用硬件里解放出来2.1 软件 PLC 到底是什么跟传统 PLC 差在哪传统 PLC 是一台专用硬件CPU、IO、通信口焊死在一块板子上你买的是西门子、三菱、罗克韦尔的整机编程用它们各自的软件逻辑跑在它们的实时操作系统上。软件 PLC 是把这套运行时软件化跑在通用 x86 工控机或者 ARM 边缘盒子上IO 通过 EtherCAT、Profinet 这些实时总线外挂。我最早接触软件 PLC 是 2018 年前后那时候稳定性还不太行跑个把月会莫名重启。现在情况好很多主流方案在工业现场连续跑一两年不出问题的案例不少。它的核心价值有三个算力可扩展想加视觉、加 AI 推理直接加 CPU 核或 GPU、部署灵活一套镜像推到一百台设备配置用代码管理、IT 生态打通能直接调 Python 库、能接消息队列、能做 CI/CD。但代价也很明确。传统 PLC 的实时性是硬件保证的扫描周期抖动通常在微秒级软件 PLC 跑在通用 OS 上如果不做实时补丁抖动可能到毫秒级对高速运动控制是致命的。所以软件 PLC 的选型第一件事就是看它的实时方案。2.2 实时性怎么保证三种主流路线对比软件 PLC 要跑实时绕不开操作系统这一层。目前工程上能落地的路线就三条我列个表对比一下。路线代表方案抖动水平适用场景我的评价实时补丁内核PREEMPT_RT Xenomai10~50 微秒中高速运动控制生态最全调优门槛高双内核/虚拟机ACRN、Jailhouse5~20 微秒高实时通用混合配置复杂硬件要求高专用实时 OSVxWorks、QNX 上跑软 PLC1~10 微秒高端装备授权贵但最稳我自己的项目里PREEMPT_RT 用得最多。原因是生态成熟Python、Docker、各种库都能直接用调优资料也多。Xenomai 的实时性更好但跟通用 Linux 的隔离做得太狠很多库用不了开发效率掉得厉害。具体怎么配 PREEMPT_RT核心是几件事CPU 隔离isolcpus把几个核专门留给实时任务、中断亲和性绑定把网卡中断绑到非实时核、关闭影响抖动的内核特性比如 CPU 频率调节、透明大页。这些参数不是拍脑袋定的要用cyclictest实测。我一般会跑 24 小时看最大抖动如果超过 100 微秒就得回去查是哪个中断在捣乱。提示cyclictest 的-m -p 80 -i 1000 -h 400 -n -l 1000000这组参数是我常用的能跑出比较真实的负载下抖动分布。别只看平均值最大值才是决定能不能用的关键。2.3 软件 PLC 的实操部署从裸机到跑通第一个逻辑我拿一个真实项目举例。客户要做一条包装线要求 8 轴伺服同步扫描周期 1 毫秒抖动不超过 50 微秒。硬件选的是一台研华工控机i7 十二代8 核32G 内存带 Intel i210 网卡这块网卡对 EtherCAT 友好。第一步是装系统。Ubuntu 22.04 打 PREEMPT_RT 补丁或者直接用已经打好补丁的镜像。装完先别急着上 PLC 运行时先做基础调优# 修改 grub隔离 2-7 核给实时任务0-1 核跑系统 GRUB_CMDLINE_LINUXisolcpus2-7 nohz_full2-7 rcu_nocbs2-7 \ intel_pstatedisable processor.max_cstate1 intel_idle.max_cstate0 \ transparent_hugepagenever这几行的意思分别是把 2 到 7 核从调度器里摘出来不让普通进程上去跑关掉这些核上的时钟中断减少干扰关掉 CPU 频率调节和深度睡眠避免唤醒延迟关掉透明大页避免内存管理带来的抖动。第二步是绑中断。用lspci -v找到 EtherCAT 网卡的中断号然后# 把网卡中断绑到 0 核别让它打扰实时核 echo 1 /proc/irq/irq_num/smp_affinity第三步装 PLC 运行时。我用过 CODESYS Runtime、Beckhoff TwinCAT/BSD、还有开源的 OpenPLC。CODESYS 生态最全支持 EtherCAT 主站授权费按设备收TwinCAT 性能最好但绑 Windows 或 BSDOpenPLC 免费但功能弱适合学习不适合产线。装完运行时配 EtherCAT 主站扫从站映射 IO。这一步跟传统 PLC 组态差不多区别在于所有配置都是文件可以进 Git。我习惯把整个运行时配置目录纳入版本管理改一个参数就提交一次出问题能回滚。第四步是写逻辑。IEC 61131-3 的五种语言都支持但我现在越来越多用ST 语言 外部 Python 脚本的组合。ST 写实时逻辑Python 做非实时的数据处理、跟 MES 通信、跑 AI 推理。两者通过共享内存或本地 socket 通信Python 崩了不影响 ST 跑。2.4 软件 PLC 的坑我踩过的几个第一个坑是网卡选型。不是所有网卡都适合做 EtherCAT 主站Realtek 的很多型号直接不行Intel i210、i219 比较稳。我一开始图便宜用了块杂牌网卡从站老是掉线换了 i210 立刻好。第二个坑是BIOS 设置。C-State、P-State、超线程、VT-d 这些选项都会影响抖动。我一般会关掉 C-State 和 P-State超线程看情况——如果实时任务核数够关掉更稳如果不够开着但要把实时任务绑到物理核上。第三个坑是内存分配。实时任务的内存最好预分配别在运行中动态申请。我见过一个项目Python 脚本跑着跑着触发 GC把实时核的缓存挤了导致扫描周期抖动超标。后来把 Python 进程绑到非实时核问题消失。第四个坑是散热。工控机塞在电柜里夏天温度能到 50 度以上CPU 降频抖动立刻上去。这个不是软件能解决的得从电柜空调或者风扇下手。3. 确定性网络让数据准时到达而不是尽力而为3.1 为什么控制层需要确定性网络传统以太网是尽力而为的数据包什么时候到不确定拥塞了就排队排队久了就丢。这在办公网络没问题但在控制层是灾难。一个运动控制指令晚到 1 毫秒伺服可能就报警了一个急停信号丢包后果更严重。传统方案是用现场总线EtherCAT、Profinet IRT、Powerlink 这些它们通过主从轮询、时间片划分来保证确定性。但现场总线的问题是带宽低、拓扑死、跟 IT 网络不通。你想在同一个网络上跑控制数据和视频流现场总线做不到。确定性网络Detnet、TSN就是来解决这个的。它在标准以太网上加了一套时间调度机制让关键流量按预定的时间窗口发送非关键流量填缝隙。这样一条线上既能跑控制又能跑视觉、跑数据采集不用拉两套网。3.2 TSN 的核心机制时间同步、调度、整形TSN 不是单一技术是一组 IEEE 802.1 标准的集合。控制层最关心的是三块时间同步802.1AS、时间感知调度802.1Qbv、流量整形802.1Qav。时间同步是基础。所有节点要有一个共同的时间基准精度到纳秒级。802.1AS 是 gPTP 的工业版本通过主时钟广播时间从时钟逐级同步。我实测下来普通交换机上能做到亚微秒级专用 TSN 交换机上能到几十纳秒。时间感知调度是核心。它把时间切成周期性的窗口每个窗口分配给特定的流量队列。比如 1 毫秒周期里前 200 微秒留给控制数据中间 500 微秒留给视频最后 300 微秒留给普通数据。交换机按这个时间表开门关门控制数据永远有独占通道。流量整形是补充。对于不能严格调度的流量用信用整形Credit-Based Shaper限制它的突发避免它挤占关键流量。3.3 实操搭一个 TSN 测试床我去年搭过一个 TSN 测试床用来验证一条视觉运动混合的产线。硬件是三台 TSN 交换机我用的是支持 802.1Qbv 的型号、一台软 PLC 工控机、一台视觉相机、一台普通 IT 服务器。第一步是配时间同步。选一台交换机做 grandmaster其他设备做 slave。配置里要指定域号、同步周期、 announce 超时这些参数。同步周期我一般设 125 微秒跟 EtherCAT 的分布式时钟对齐。第二步是配流量分类。把控制数据打上 VLAN 优先级 7视频流打 5普通数据打 0。然后在交换机上配 Qbv 门控列表# 伪代码实际配置看交换机厂商 GateControlList: - Time: 0us, Gates: [7:open, 5:closed, 0:closed] - Time: 200us, Gates: [7:closed, 5:open, 0:closed] - Time: 700us, Gates: [7:closed, 5:closed, 0:open] - Time: 1000us, Gates: [7:open, 5:closed, 0:closed]这个列表的意思是每个 1 毫秒周期前 200 微秒只放控制数据中间 500 微秒放视频最后 300 微秒放普通数据。控制数据的窗口是独占的视频和普通数据抢不到。第三步是验证。用ping测延迟没用要看抖动分布。我用的是tsn_listener这类工具抓每个周期的到达时间算最大偏差。实测下来控制数据的抖动在 1 微秒以内视频流在 100 微秒以内普通数据在毫秒级但无所谓。3.4 确定性网络的选型与部署注意事项选交换机是第一道关。不是所有标TSN的交换机都支持 Qbv有些只支持 Qav 或者只支持时间同步。买之前一定要确认支持 802.1Qbv而且门控列表的粒度要够细至少 8 个队列。第二道关是端设备支持。软 PLC 的网卡要支持硬件时间戳不然同步精度上不去。我用的 i210 支持但有些便宜的网卡不支持同步误差能到几十微秒。第三道关是配置复杂度。Qbv 的门控列表要跟控制周期严格对齐配错了要么控制数据被挤要么带宽浪费。我一般会先用仿真工具算一遍再上实际设备。注意TSN 的时间同步对网络拓扑有要求环形拓扑要做冗余的话配置会复杂很多。如果产线规模不大星型拓扑最省事。还有一个容易被忽略的点TSN 交换机的时间同步域要跟现场总线对齐。如果一边用 EtherCAT 的分布式时钟一边用 gPTP两个时间基准不一致数据融合的时候会出问题。我的做法是让 gPTP 跟 EtherCAT 的参考时钟同步或者干脆用同一个时钟源。4. AI 进入控制层从事后分析到实时参与4.1 AI 在控制层的三种角色AI 进控制层不是让 AI 直接输出控制指令——那太危险了。目前能落地的有三种角色参数寻优、异常检测、预测性补偿。参数寻优是最成熟的。比如注塑机的温度曲线、包装机的张力设定传统靠老师傅调现在可以用强化学习或者贝叶斯优化自动找最优参数。AI 不直接控制它给 PLC 下发设定值PLC 还是按原来的逻辑跑。异常检测是第二成熟的。用振动、电流、温度这些信号训练一个自编码器或者孤立森林实时判断设备状态。异常了给 PLC 一个信号PLC 决定是降速还是停机。预测性补偿是最前沿的。比如机械臂的轨迹跟踪传统 PID 在高速下会有滞后用神经网络预测滞后量提前补偿。这个对实时性要求最高模型推理要在几百微秒内完成。4.2 模型怎么部署到控制层三种架构AI 模型跑在哪决定了整个架构。我列三种我实际用过的。第一种模型跑在软 PLC 同一台机器的非实时核上。这是最简单的。Python 进程绑到非实时核通过共享内存跟 ST 逻辑通信。优点是延迟低同一台机器共享内存通信在微秒级缺点是模型不能太大不然抢 CPU 影响实时任务。适合轻量模型比如几层的 MLP 或者小型的 LSTM。第二种模型跑在边缘服务器上通过 TSN 网络跟 PLC 通信。边缘服务器可以配 GPU跑大一点的模型。通信走 TSN 的确定性通道延迟可控。缺点是多了网络这一跳端到端延迟比第一种高但通常也在毫秒级以内。适合视觉检测、复杂预测这类场景。第三种模型跑在云端PLC 只做推理结果的执行。这个延迟最大通常只用于非实时的参数优化比如每天跑一次寻优把新参数下发给 PLC。实时控制回路不依赖云端。我自己的项目里第一种和第二种用得最多。第一种适合快速验证第二种适合正式部署。第三种只在参数寻优场景用。4.3 实操把一个小模型塞进控制回路我拿一个真实案例讲。客户有一条薄膜生产线张力控制老是不稳传统 PID 在换卷的时候会波动。我们做了一个 LSTM 模型输入是最近 200 毫秒的张力、速度、卷径输出是 PID 参数的修正量。模型很小两层 LSTM隐藏层 32参数量不到一万。训练用历史数据离线做。部署的时候模型转成 ONNX用 onnxruntime 跑在工控机的非实时核上。通信用的是共享内存。ST 逻辑每个扫描周期把输入写到一个共享内存区Python 进程读出来推理把输出写回另一个区。ST 逻辑下一个周期读输出应用到 PID 上。这里有几个关键点。第一是同步共享内存要加锁或者用无锁环形缓冲不然会读到半截数据。我用的是双缓冲加原子标志位简单可靠。第二是超时Python 进程如果卡住ST 逻辑不能等要用上一次的输出或者回退到默认 PID。第三是模型更新新模型上线不能停线我的做法是双模型热切换新模型先在影子模式跑对比输出确认没问题再切。实测下来换卷时的张力波动从正负 8% 降到正负 3%效果明显。推理延迟平均 80 微秒最大 200 微秒对 1 毫秒的扫描周期来说完全够用。4.4 AI 进控制层的风险与边界AI 进控制层最大的风险是不可解释。传统 PID 你还能分析神经网络出问题你都不知道为什么。所以我的原则是AI 只做建议不做决策。最终的控制指令还是由确定性逻辑发出AI 的输出要经过限幅、速率限制、合理性检查才能生效。第二个风险是数据漂移。模型训练用的数据跟实际运行的数据分布不一致效果会掉。我一般会加一个在线监控统计输入输出的分布偏移超过阈值就报警提示重新训练。第三个风险是实时性不达标。模型推理时间波动大偶尔超过扫描周期会导致控制抖动。解决办法是给推理设硬超时超时就回退同时监控超时率高了就优化模型或者换硬件。提示AI 模型进控制层之前一定要在影子模式跑至少两周对比它跟原逻辑的输出差异。我见过直接上线的项目模型在某个工况下输出异常值导致整批产品报废。5. 三件事怎么凑到一起一个融合架构的落地记录5.1 整体架构设计我把上面三块技术整合到一个项目里客户是一条精密装配线要求节拍 0.8 秒良率 99.5% 以上。原来的架构是传统 PLC 现场总线 独立视觉系统数据不通换型要人工调半天。新架构是这样的软 PLC 跑在工控机上EtherCAT 接伺服和 IOTSN 网络接视觉相机和边缘服务器AI 模型跑在边缘服务器上做视觉检测和参数寻优。IT 侧通过 OPC UA 跟 MES 通信数据进时序数据库。这个架构的核心思路是分层确定性。最底层是 EtherCAT保证运动控制的微秒级确定性中间层是 TSN保证视觉和 AI 推理的毫秒级确定性最上层是普通以太网跑 MES 和数据采集尽力而为就行。5.2 关键环节的实现细节时间同步是第一个要解决的。EtherCAT 有自己的分布式时钟TSN 用 gPTP两者要对齐。我的做法是让工控机同时做 EtherCAT 主站和 gPTP grandmaster用一个时钟源驱动两者。这样视觉相机的时间戳跟伺服的位置能对上做视觉引导的时候不用做时间对齐。数据流是第二个要设计的。视觉相机的图像走 TSN 到边缘服务器推理结果走 TSN 回工控机。工控机上的软 PLC 把结果跟运动指令融合下发给伺服。整个过程要在 0.8 秒节拍内完成留给视觉和推理的时间大概 300 毫秒。AI 模型是第三个要调的。视觉检测用的是 YOLO 的小型版本输入 640x640推理在边缘服务器的 GPU 上跑单帧 15 毫秒。参数寻优用的是贝叶斯优化每生产 100 件跑一次调整装配压力曲线。5.3 实测数据与效果项目跑了三个月我记录了一些数据。控制回路的抖动软 PLC 侧最大 45 微秒满足 50 微秒的要求。TSN 网络的端到端延迟视觉图像从相机到边缘服务器平均 1.2 毫秒最大 2.5 毫秒。AI 推理延迟平均 18 毫秒最大 35 毫秒。良率从原来的 98.2% 提到 99.6%换型时间从 30 分钟降到 5 分钟。这些提升主要来自 AI 参数寻优和视觉检测的实时反馈不是单一技术的功劳。5.4 这个架构的适用边界不是所有产线都适合这么搞。节拍太快的比如 0.1 秒以内TSN 和 AI 的延迟占比太高不划算。产品太单一的参数寻优没意义传统 PLC 够用。预算太紧的TSN 交换机和边缘服务器都不便宜回本周期要算清楚。我的判断标准是如果换型频繁、质量要求高、数据要打通那值得上如果是大批量单一品种传统方案更经济。6. 常见问题与排查技巧实录6.1 软 PLC 抖动超标怎么查抖动超标是最常见的问题。我的排查顺序是先看 CPU 隔离有没有生效cat /proc/cmdline确认 isolcpus再看中断有没有绑对cat /proc/interrupts看实时核上的中断数然后看有没有其他进程在抢top -H看实时核上的线程最后看 BIOS 设置C-State、P-State 有没有关。如果这些都排除了还超标用ftrace抓一下实时任务的调度延迟看是哪个环节引入的。我遇到过一次是网卡驱动的问题换了个驱动版本就好了。6.2 TSN 时间同步不上的排查同步不上先看物理层。网线、光模块、交换机端口这些基础的东西最容易出问题。然后看配置域号、优先级、同步周期两边要一致。再看交换机的时间戳能力有些交换机只支持软件时间戳精度上不去。我遇到过一次是交换机的固件 buggPTP 报文处理有问题升级固件解决。还有一次是网络里有非 TSN 设备在发 gPTP 报文干扰了主时钟选举把那个设备隔离就好了。6.3 AI 模型推理超时怎么处理推理超时先看模型大小。如果模型太大换小模型或者做量化。再看硬件CPU 推理慢就换 GPU 或者 NPU。再看进程优先级推理进程要绑到非实时核但优先级要够高别被其他进程挤。如果这些都做了还超时那就是模型本身的问题输入数据分布变了推理路径变长。这时候要加监控统计推理时间的分布超阈值就报警。6.4 常见问题速查表问题现象可能原因排查方法解决方向软 PLC 抖动超标CPU 隔离失效查 /proc/cmdline重新配 grub软 PLC 抖动超标中断未绑定查 /proc/interrupts绑中断到非实时核EtherCAT 从站掉线网卡不兼容换 Intel 网卡测试换 i210/i219TSN 同步不上域号不一致查两边配置统一域号TSN 同步不上非 TSN 设备干扰抓包看 gPTP 报文隔离干扰设备AI 推理超时模型太大测推理时间量化或换小模型AI 推理超时进程被挤查 CPU 占用提优先级或绑核视觉引导偏差时间戳不对齐对比两边时间统一时钟源6.5 几个独家避坑技巧第一个软 PLC 的工控机BIOS 里一定要关掉 Energy Efficient Turbo 或者类似的节能选项。我见过一个项目CPU 在低负载时降频负载上来时升频有延迟导致抖动周期性超标。关掉之后立刻好。第二个TSN 交换机的门控列表周期要跟控制周期成整数倍关系。比如控制周期 1 毫秒门控周期就设 1 毫秒或者 2 毫秒别设 1.5 毫秒不然会有累积误差。第三个AI 模型的输入要做归一化和异常值过滤。我见过模型因为一个传感器瞬时跳变输出离谱值导致整批产品参数跑偏。加一个简单的限幅和滑动平均就能避免。第四个所有配置都要进版本管理。软 PLC 的运行时配置、TSN 的门控列表、AI 模型的版本全部用 Git 管起来。出问题能回滚换型能复用这是 IT 那套东西带给 OT 的最大价值。第五个上线前一定要做压力测试。模拟最坏工况比如所有轴同时加速、视觉满负荷、AI 推理排队看抖动和延迟还满不满足。我一般会跑 72 小时覆盖各种工况组合。7. 这套东西后续还能怎么扩展我现在在试的一个方向是多 AI 协作。不是一个大模型包打天下而是几个小模型各管一块——一个管视觉、一个管参数、一个管异常检测它们之间通过消息总线通信互相校验。这样单个模型出问题不会影响全局也更容易迭代。另一个方向是控制逻辑的自动化生成。用 AI 读工艺文档和 historan 数据自动生成 ST 代码框架工程师只做审核和微调。这个还在早期但已经有苗头了。还有一个是数字孪生跟控制层的闭环。孪生模型实时跟产线同步在虚拟环境里试新参数验证通过再下发到实际 PLC。这个对换型频繁的产线价值很大能大幅减少试错成本。我个人在实际操作中的体会是IT/OT 融合最难的不是技术是两边人的思维差异。IT 的人要理解现场的物理约束OT 的人要接受软件工程的迭代方式。技术方案再漂亮两边不配合也落不了地。所以我现在做项目第一步不是选型是把两边的人拉到一起先对齐目标再谈技术。这个顺序错了后面全是坑。